View PEB20320_143886.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

ICs for Communications
Multichannel Network Interface Controller for HDLC MUNICH32 PEB 20320 Version 3.4
User's Manual 01.2000
DS3
*
PEB 20320 Revision History: Previous Version: Page (in previous Version) Page (in current Version) Current Version: 01.2000 User's Manual 1998-06-01 DS2 (V3.4) Subjects (major changes since last revision)
Package P-TQFP-176-1 removed from User's Manual. For questions on technology, delivery and prices please contact the Infineon Technologies Offices in Germany or the Infineon Technologies Companies and Representatives worldwide: see our webpage at http://www.infineon.com
*
ABM(R), AOP(R), ARCOFI(R), ARCOFI(R)-BA, ARCOFI(R)-SP, DigiTape(R), EPIC(R)-1, EPIC(R)-S, ELIC(R), FALC(R)54, FALC(R)56, FALC(R)-E1, FALC(R)-LH, IDEC(R), IOM(R), IOM(R)-1, IOM(R)-2, IPAT(R)-2, ISAC(R)-P, ISAC(R)-S, ISAC(R)-S TE, ISAC(R)-P TE, ITAC(R), IWE(R), MUSAC(R)-A, OCTAT(R)-P, QUAT(R)-S, SICAT(R), SICOFI(R), SICOFI(R)-2, SICOFI(R)-4, SICOFI(R)-4C, SLICOFI(R) are registered trademarks of Infineon Technologies AG. ACETM, ASMTM, ASPTM, POTSWIRETM, QuadFALCTM, SCOUTTM are trademarks of Infineon Technologies AG. Edition 01.2000 Published by Infineon Technologies AG, SC, Balanstrae 73, 81541 Munchen (c) Infineon Technologies AG 2000. All Rights Reserved. Attention please! As far as patents or other rights of third parties are concerned, liability is only assumed for components, not for applications, processes and circuits implemented within components or assemblies. The information describes the type of component and shall not be considered as assured characteristics. Terms of delivery and rights to change design reserved. Due to technical requirements components may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies Office. Infineon Technologies AG is an approved CECC manufacturer. Packing Please use the recycling operators known to you. We can also help you - get in touch with your nearest sales office. By agreement we will take packing material back, if it is sorted. You must bear the costs of transport. For packing material that is returned to us unsorted or which we are not obliged to accept, we shall have to invoice you for any costs incurred. Components used in life-support devices or systems must be expressly authorized for such purpose! Critical components1 of the Infineon Technologies AG, may only be used in life-support devices or systems2 with the express written approval of the Infineon Technologies AG. 1 A critical component is a component used in a life-support device or system whose failure can reasonably be expected to cause the failure of that life-support device or system, or to affect its safety or effectiveness of that device or system. 2 Life support devices or systems are intended (a) to be implanted in the human body, or (b) to support and/or maintain and sustain human life. If they fail, it is reasonable to assume that the health of the user may be endangered.
PEB 20320
Preface
The Multichannel Network Interface Controller for HDLC (MUNICH32) is a Multichannel Protocol Controller for a wide area of telecommunication and data communication applications. Organization of this Document This User's Manual is divided into 9 chapters. It is organized as follows: * Chapter 1, Introduction Gives a general description of the product and its family, lists the key features, and presents some typical applications. * Chapter 2, Functional Description This chapter provides a detailed description of the interfaces and the protocol modes. * Chapter 3, Operational Description Provides a description of MUNICH32 reset procedure and initialization. * Chapter 4, Detailed Register Description Gives a detailed description of the shared memory organization. * Chapter 5, Application Notes * Chapter 6, Application Hints * Chapter 7, Electrical Characteristics Gives a detailed description of all electrical DC and AC characteristics and provides timing diagrams and values for all interfaces. * Chapter 8, Package Outlines * Chapter 9, Appendix This chapter provides source code examples. Your Comments We welcome your comments on this document as we are continuously aiming at improving our documentation. Please send your remarks and suggestions by e-mail to sc.docu_comments@infineon.com Please provide in the subject of your e-mail: device name (MUNICH32), device number (PEB 20320), device version (Version 3.4), and in the body of your e-mail: document type (User's Manual), issue date (01.2000) and document revision number (DS3).
User's Manual
3
01.2000
PEB 20320
User's Manual
4
01.2000
PEB 20320
Table of Contents 1 1.1 1.2 1.3 1.4 1.5 1.6 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 2.4 2.5 3 3.1 3.2 4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3 4.4 5 5.1 5.1.1 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.4 5.1.2 5.1.3 5.1.3.1
Page
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Pin Definitions and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Logic Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Microprocessor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Intel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Motorola Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 DMA Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Basic Functional Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Detailed Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76 Boundary Scan Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126 Operational Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Reset State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Initialization Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Detailed Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Organization of the Shared Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Control and Configuration Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 Action Specification (Read Once After Each Action Request Pulse) . . .136 Interrupt Queue Specification . . . . . . . . . . . . . . . . . . . . . . .140 Interrupt Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 Time Slot Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Channel Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149 Current Receive and Transmit Descriptor Address . . . . . . . . . . . . . .161 Transmit Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162 Receive Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168 Application Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Test Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Test Loop Definitions for the MUNICH32 . . . . . . . . . . . . . . . . . . . . . . .173 Internal Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 External Complete Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .174 External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 Test Loop Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176 Test Loop Deactivation and Switching . . . . . . . . . . . . . . . . . . . . . . . . . .176 Software Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
5 01.2000
User's Manual
PEB 20320
Table of Contents 5.1.3.2 5.1.4 5.1.4.1 5.1.4.2 5.2 5.2.1 5.2.2 5.2.3 5.2.3.1 5.2.3.2 5.2.4 5.2.5 5.2.6 5.2.7 5.3 5.3.1 5.3.2 6 6.1 6.2 6.3 6.3.1 6.3.2 7 7.1 7.2 7.3 7.4 7.5 7.6 8 9 9.1 9.2
Page
Hardware Reset Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 Test Loop Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 Internal Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .178 External Channelwise Test Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . .180 MUNICH32 in a LAN/WAN Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .183 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Device Driver Module MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . .191 Application Module MROUTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194 Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197 Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201 Adaption of the 68040 P Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203 Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205 Memory Bus Occupancy for a Single MUNICH32 . . . . . . . . . . . . . . . . . . .214 Bus Occupancy Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217 Bus Occupancy for Idle Tx Channels . . . . . . . . . . . . . . . . . . . . . . . . . .218 Application Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220 Frequency Adaption in an Intel 368 Common Bus System . . . . . . . . . . . .220 MUNICH32 Memory Space Requirement . . . . . . . . . . . . . . . . . . . . . . . . .223 Serial Interface to different PCM Systems . . . . . . . . . . . . . . . . . . . . . . . . .224 MUNICH32 for SIEMENS Primary Access Interface . . . . . . . . . . . . . . .224 MUNICH32 in Systems with MITEL ST BUS . . . . . . . . . . . . . . . . . . . . .227 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230 Capacitances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231 Microprocessor Interface Intel Bus Mode . . . . . . . . . . . . . . . . . . . . . . . . .232 Microprocessor Interface Motorola Bus Mode . . . . . . . . . . . . . . . . . . . . . .235 Package Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Source Code Extract MUNICH32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
User's Manual
6
01.2000
PEB 20320
Introduction 1 Introduction
The Multichannel Network Interface Controller for HDLC (MUNICH32) is a Multichannel Protocol Controller, which handles up to 32 data channels of a full duplex PCM highway. It performs layer 2 HDLC formatting/deformatting or V.110 and X.30 protocols up to a network data rate of 38.4 Kbit/s as well as transparent transmission for the DMI mode 0, 1 and 2. The processed data is passed on to an external memory shared with one or more host processors. MUNICH32 is compatible with the LAPD ISDN (Integrated Services Digital Network) protocol specified by CCITT as well as with HDLC, SDLC, LAPB DMI protocols. It provides any rate adaption for time slot transmission data rate from 64 Kbit/s down to 8 Kbit/s and the concatenation of any time slots to data channels, supporting the ISDN H0, H11, H12 superchannels. Due to these functions the MUNICH32 can be used in a wide area of telecommunication and data communication applications, e.g. in central office switches, for the connection of a digital PABX to a host computer, as a central D-channel controller to 32 ISDN basic access D-channels or as a multiplexer for terminals and other peripherals. Up to 4 MUNICH32s can be connected to one PCM highway, so a D-channel controller with 128 channels can be achieved.
User's Manual
7
01.2000
Multichannel Network Interface Controller for HDLC MUNICH32
PEB 20320
Version 3.4 1.1 Features
CMOS
* Serial Interface - Up to 32 independent communication channels. - Serial multiplexed (full duplex) input/output for 2048-, 4096-, 1544- or 1536-Kbit/s PCM highways. * Dynamic Programmable Channel Allocation - Compatible with T1/DS1 24-channel and CEPT 32-channel PCM byte format.
P-MQFP-160-1
- Concatenation of any, not necessarily consecutive, time slots to superchannels independently for receive and transmit direction. - Support of H0, H11, H12 ISDN-channels. - Subchanneling on each time slot possible. * Bit Processor Functions (adjustable for each channel) - HDLC Protocol - Automatic flag detection and transmission - Shared opening and closing flag - Detection of interframe-time-fill change, generation of interframe-time-fill `1's or flags - Zero bit insertion - Flag stuffing and flag adjustment for rate adaption - CRC generation and checking (16 or 32 bits) - Transparent CRC option per channel and/or per message - Error detection (abort, long frame, CRC error, 2 categories of short frames, non-octet frame content) - Special short frame mode to allow reception of `frames' with a least on byte length - ABORT/IDLE generation
Type PEB 20320
User's Manual 8
Package P-MQFP-160-1
01.2000
PEB 20320
Introduction - V.110/X.30 Protocol - Automatic synchronization in receive direction, automatic generation of the synchronization pattern in transmit direction - E / S / X bits freely programmable in transmit direction, van be changed during transmission; changes monitored and reported in receive direction - Generation/detection of loss of synchronism - Bit framing with network data rates from 600 bit/s up to 38.4 Kbit/s - Transparent Mode A - Slot synchronous transparent transmission/reception without frame structure - Bit-overwrite with fill/mask bits - Flag generation, flag stuffing, flag extraction, flag generation in the abort case with programmable flag - Transparent Mode B - Transparent transmission/reception in frames delimited by 00H flags - Shared opening and closing flag - Flag stuffing, flag detection, flag generation in the abort case - Error detection (non octet frame content, short frame, long frame) - Transparent Mode R - Transparent transmission/reception with GSM 08.60 frame structure - Automatic 0000H flag generation/detection - Support of 40, 391/2, 401/2 octet frames - Error detection (non octet frame content, short frame, long frame) - Protocol Independent - Channel inversion (data, flags, IDLE code) - Format conventions as in CCITT Q.921 2.8 - Data over- and underflow detected * Processor Interface - ON-CHIP 64-channel DMA controller with buffer chaining capability. - Compatible with Motorola 68020 processor family and Intel 32-bit processor (80386). - 32 bit data bus and 32 bit address bus (4 Gbyte RAM addressable, Motorola and Intel non-parity) or 28 bit address bus (256 Mbyte RAM addressable, Intel parity) - Intel parity mode with data byte parity (4 parity bits) - Parity check for read accesses - Parity generation for write accesses - Interrupt-circular buffer with variable size - Maskable interrupts for each channel - P interface buffer of depth 16 long words for adaptive bus occupation
User's Manual
9
01.2000
PEB 20320
Introduction * General - Connection of up to four MUNICH32 supporting a 128-channel basic access D-channel controller. - ON-CHIP receive and transmit data buffer; the buffer size is 256 bytes each. - HDLC protocol or transparent mode, support of ECMA 102, CCITT I4.63 RA2, V.110, X.30, DMI mode 0, 1, 2 (bit rate adaption), GSM 08.60 TRAU frames. - LOOP mode, complete loop as well as single channel loop - JTAG boundary scan test - Advanced low-power CMOS technology - TTL-compatible inputs/outputs - 160 pin P-MQFP package
User's Manual
10
01.2000
PEB 20320
Introduction 1.2 Pin Configuration (top view)
P-MQFP-160-1
D8 A8 VSS V DD D9 A9 D10 A10 VDD VSS VDD D11 A11 D12 A12 VSS VDD D13 A13 VDD VSS D14 A14 VSS VDD D15 A15 D16 A16 VSS VSS VDD D17 A17 D18 A18 VSS VDD D19 A19
120 121
A7 D7 V DD V SS A6 D6 A5 D5 V DD V SS V SS A4 D4 A3 D3 V DD V SS V SS A2 D2 BE0 D1 V DD V SS BE1 D0 BE2 VDD V SS BE3 W,R/R;W V DD V SS V SS DS/PCHK ADS/AS V DD V SS HOLD/BR BGACK/PM
110
100
90
81 80
130 70
140
MUNICH32 PEB 20320
60
150 50
Index Marking
160 1 10 20 30 41 40
HLDAO/BGO HLDA/BG V DD V SS BERR READY/DSACK B16 I/M N.C. N.C. N.C. TCLK TSP TDATA AR TEST V SS V DD V SS SCLK RESET V SS V DD V DD JTEST3 JTEST2 JTEST1 JTEST0 N.C. CI4 CI3 CI2 CI1 CI0 RDATA RSP RCLK N.C. N.C. N.C.
D20 A20 V SS V DD D21 A21 D22 A22 V SS V SS V DD D23 A23 D24 A24 V SS V DD D25 A25 D26 A26 V SS V SS V DD D27 A27 D28 A28/DP0 V SS V SS V DD D29 A29/DP1 D30 A30/DP2 V SS V DD D31 A31/DP3 INT/INT
ITP03487
Figure 1
User's Manual 11 01.2000
PEB 20320
Introduction 1.3 Pin Definitions and Functions
Pin Definitions and Functions Pin No. P-MQFP-160-1 83, 87, 88, 92, 97, 103, 104, 110, 111, 117, 123, 130, 136, 141, 144, 150, 151, 157, 3, 9, 10, 16, 22, 23, 29, 30, 36, 59, 62, 64, 77 73 Symbol Input (I) Function Output (O) I Ground (0 V) All pins must have the same level.
VSS
I/M
I
Intel Bus Mode or Motorola Bus Mode By connecting this pin to either VSS or VDD the bus interface can be adapted to either Intel or Motorola environment. The data is interpreted either in Intel or Motorola manner; i.e. little or big endian convention. I/M = low: Intel bus mode I/M = high: Motorola bus mode Address Bit 31 (Intel non-parity/Motorola) tristate when unused. Data Parity 3 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(31:24). Address Bit 30 (Intel non-parity/Motorola) tristate when unused. Data Parity 2 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(23:16).
39
A31
O
DP3
I/O
35
A30
O
DP2
I/O
Note: Input pins that are unused in a specific configuration must be strapped to VSS. I/O or output pins that are unused in a specific configuration must be left open!
User's Manual
12
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 33 Symbol A29 Input (I) Function Output (O) O Address Bit 29 (Intel non-parity/Motorola) tristate when unused. Data Parity 1 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(15:8) Address Bit 28 (Intel non-parity/Motorola) tristate when unused Data Parity 0 (Intel parity mode), bidirectional tristate line containing/ expecting parity bit of D(7:0) Address Bus tristate when unused.
DP1
I/O
28
A28
O
DP0
I/O
26, 21, 19, 15, A(27:2) 13, 8, 6, 2, 160, 156, 154, 149, 147, 143, 139, 135, 133, 128, 126, 122, 120, 116, 114, 109, 107, 102 91, 94, 96, 100 BE(3:0)
O
O
Byte Enable (Intel bus mode) The MUNICH32 provides word and long word transfer. The byte enables determine the address offset to the address A31 ... A2, the actual word has been stored to. Address Offset Size (Motorola mode) Indicates the number of bytes remaining to be transferred for this access. These signals define the active sections of the data bus. In both cases these signals are tristate when unused. See Chapter 2.2 for details.
User's Manual
13
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 Symbol Input (I) Function Output (O) I/O Data Bus The data bus lines are bidirectional tristate lines which interface with the system's data bus.
38, 34, 32, 27, D(31:0) 25, 20, 18, 14, 12, 7, 5, 1, 159, 153, 148, 146, 142, 138, 134, 132, 127, 125, 121, 119, 115, 113, 108, 106, 101, 99, 95 86 DS
O
Data Strobe (Motorola mode) This signal indicates that valid data is to be placed on the data bus (read cycle) or has been placed on the data bus by the MUNICH32 (write cycle). Parity Check (Intel parity mode) This signal indicates, whether the parity bits of a read cycle are valid (PCHK high) or invalid (PCHK low). See Chapter 2.2.1 for details. Supply voltage 5 V 5% All pins must have the same level.
PCHK
O
84, 93, 89, 98, 105, 112, 118, 124, 129, 131, 137, 140, 145, 152, 158, 4, 11 , 17, 24, 31, 37, 57, 58, 63, 78 85
VDD
I
ADS
O
Address Status (Intel bus mode) This signal indicates that a valid bus cycle definition and address are being driven at the pins. Address Strobe (Motorola bus mode) A valid address is transmitted on the address bus at the falling edge of AS. In both cases this signal is active low and tristate when unused.
AS
O
User's Manual
14
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 90 Symbol W/R Input (I) Function Output (O) O Write/Read (Intel bus mode) This signal distinguishes write from read operations. Read/Write (Motorola bus mode) This signal distinguishes between read and write operations. In both cases this signal is tristate when unused. 75 READY I Ready (Intel bus mode) This signal indicates that the current bus cycle is complete. When READY is asserted during a read cycle the MUNICH32 latches the input data and terminates the cycle. When READY is asserted during a write cycle the MUNICH32 terminates the cycle. Data Transfer Acknowledge (Motorola bus mode) This active low input indicates that a data transfer may be performed. During a read cycle data becomes valid at the falling edge of DSACK. The data is latched internally and the bus cycle is terminated. During a write cycle the falling edge of DSACK marks the latching of data and the bus cycle is terminated.
R/W
O
DSACK
I
User's Manual
15
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 76 Symbol BERR Input (I) Function Output (O) I Bus Error (Intel and Motorola bus mode) This active low signal informs the MUNICH32 that a bus cycle error has occurred. The MUNICH32 terminates the bus cycle. In case of an erroneous read cycle in the control and configuration section an `Action Request Fail' interrupt is generated and the action is suspended. In case of an erroneous read cycle in the transmit data section the corresponding frame is aborted and a FO interrupt is generated. In all other cases of read or write cycles terminated with an error condition no further actions are performed by the MUNICH32. Please see Chapter 2.2, `Microprocessor Interface', first paragraph and Figure 18. As bus cycles are executed without time limit this signal prevents a hang-up situation of the MUNICH32. Word Operation Setting this bit to VDD causes the MUNICH32 to perform 32-bit long word accesses to the shared memory, setting it to VSS causes the MUNICH32 to perform 16-bit word accesses on the data lines D(15:0) only. In 16-bit word access mode the data lines D(31:16) should be left open. This bit is not dynamic and should be set to VDD in Intel parity mode.
74
B16
I
User's Manual
16
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 82 Symbol HOLD Input (I) Function Output (O) O Bus Hold Request (Intel bus mode) This signal is driven high when the MUNICH32 requests the control of the bus. Bus Request (Motorola bus mode) This signal is driven low when the MUNICH32 requests the control of the bus and is interpreted when another MUNICH32 wants to be the bus master. Bus Hold Acknowledge (Intel bus mode) This active high signal indicates that the processor has released the control of the bus. The MUNICH32 starts the bus cycles. Bus Grant (Motorola bus mode) This active low signal indicates that the MUNICH32 may assume the bus mastership. Bus Grant Acknowledge (Motorola bus mode) This signal is driven low by the device, when it has become the bus master. It also informs the MUNICH32 whether another device is bus master. Parity Mode (Intel bus mode) This signal has to be strapped to VDD before reset to enable the Intel parity mode or to VSS before reset to enable the Intel non-parity mode. It has to be left strapped during reset and operation.
BR
I/O
79
HLDA
I
BG
I
81
BGACK
I/O
PM
I
User's Manual
17
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 80 Symbol HLDAO Input (I) Function Output (O) O Bus Hold Acknowledge Passing ON (Intel bus mode) If another MUNICH32 has initiated a HOLD REQUEST the HOLD ACKNOWLEDGE is passed on via HLDAO. The MUNICH32 does not give another HOLD REQUEST before the HOLD ACKNOWLEDGE has been deactivated in order to prevent blocking in the case of continuous request by one MUNICH32. Bus Grant Acknowledge (Motorola bus mode) If the MUNICH32 has not requested the bus mastership it passes on the BUS GRANT. The MUNICH32 does not give another BUS REQUEST before the BUS REQUEST and the BUS GRANT ACKNOWLEDGE have been deactivated in order to prevent blocking in the case of continuous request by one MUNICH32. Action Request AR must be pulsed low to cause an action of the MUNICH32. The AR is activated for updating the mode and channel configurations, setting a test loop, or initializing the interrupt queue. The min. time between Reset and first AR is 500 s.
BGO
O
66
AR
I
User's Manual
18
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 40 Symbol INT/INT Input (I) Function Output (O) O Interrupt Request An interrupt is given when a transmission/ reception error is detected, frames are received or transmitted, or a host initiated action is performed. The interrupt pulse signal interacts with a write cycle to the shared memory. The data written into the interrupt queue contains the interrupt specification. The interrupt is active high for Intel bus mode and active low for Motorola bus mode. Receive Clock This clock provides the data clock for RDA T1/DS1 24-channel 1.544 MHz 24-channel 1.536 MHz CEPT 32-channel 2.048 MHz 32-channel 4.096 MHz Receive Synchronization Pulse This signal provides the reference for the receive PCM frame synchronization. It marks the first bit in the PCM frame. Receive Data Serial data is received at this PCM input port. The MUNICH32 supports the T1/ DS1 24-channel PCM format, the CEPT 32-channel PCM format as well as a 32channel PCM format with 4.096-Mbit/s bit rate. System Clock PCM highway system clock highway frequency 32-channel 16.384 MHz 2.048 or 4.096 MHz 24-channel 12.288 MHz 1.536 MHz 24-channel 12.352 MHz 1.544 MHz
44
RCLK
I
45
RSP
I
46
RDATA
I
61
SCLK
I
User's Manual
19
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 51 ... 47 Symbol CI(4:0) Input (I) Function Output (O) I Chip Identification Up to four MUNICH32 can be connected to the PCM highway. These inputs define the start address of the control section pointer in the shared memory. CI4 is the polarity of A31 ... A22 CI3 is the polarity of A21 ... A16 CI2 is the polarity of A15 ... A4 CI1 is the polarity of A3 CI0 is the polarity of A2 A1, A0 are always `00' Test Pins The MUNICH32 supports the JTAG boundary scan test and the JTAG test standards. Test If this bit is set to VDD MUNICH32 works in a test mode. For the functional working mode this bit must be set to VSS. Transmit Data Serial data is sent by this PCM output port is push-pull for active bits in the PCM frame and tristate for inactive bits. Transmit Synchronization Pulse This signal provides the reference for the transmit frame synchronization. It marks the last bit in the PCM frame. Transmit Clock This clock provides the data clock for TDATA T1/DS1 24-channel 1.544 MHz 24-channel 1.536 MHz CEPT 32-channel 2.048 MHz 32-channel 4.096 MHz
56 ... 53
JTEST (3:0)
I/O
65
TEST
I
67
TDATA
O
68
TSP
I
69
TCLK
I
User's Manual
20
01.2000
PEB 20320
Introduction Pin Definitions and Functions (cont'd) Pin No. P-MQFP-160-1 60 41, 42, 43, 52, 70, 71, 72 Symbol RESET N.C. Input (I) Function Output (O) I Reset No Connect These pins are reserved and should not be connected
User's Manual
21
01.2000
PEB 20320
Introduction 1.4 Logic Symbol
BE (3:0)
VSS 30 RCLK RSP 32 RDATA TCLK TSP TDATA
Serial Interface
1) D (31:0)
W/R R/W ADS/AS
Microprocessor Bus Interface
DS/PCHK READY/DSACK BERR B16 HOLD/BR HLDA/BG BGACK/PM HLDAO/BGO AR INT/INT
MUNICH32 PEB 20320
5
I/M
CI (4:0)
4
TEST
JTEST (3:0)
System Interface
RESET SCLK VDD
ITL03488
1) A31/DP3, A30/DP2, A29/DP1, A28/DP0, A[27:2]
Figure 2 MUNICH32 Logic Symbol
User's Manual
22
01.2000
PEB 20320
Introduction 1.5 Functional Block Diagram
TCLK
TSP
TDATA
TEST RESET SCLK
JTEST
CI (4:0)
RCLK
RSP RDATA
4
5
CD
Serial Interface/Formatter Controller Unit
TF Transmit Formatter
CSR Configuration and State RAM
RD Receive Deformatter
TB Transmit Buffer
CM DMA Controller
RB Receive Buffer
MI
Microprocessor Bus Interface
32
BE (3:0) A (31:2) D (31:0)
ADS/ DS W/R READY/ HOLD/ HLDA/ BGACK HLDAO/ R/W DSACK BR AS BGO BG PM
BERR INT/ AR B16 I/M ITB03495 INT
Figure 3 Block Diagram of MUNICH32
User's Manual 23 01.2000
PEB 20320
Introduction The internal functions of MUNICH32 are partitioned into 8 major blocks. 1. Serial Interface, Formatter Control Unit CD - Parallel-Serial conversion, PCM timing, switching of the test loops, controlling of the multiplex procedure. 2. Transmit Formatter TF - HDLC frame, bit stuffing, flag generation, flag stuffing and adjustment, CRC generation, transparent mode transmission and V.110, X.30 80 bit framing. 3. Transmit Buffer TB - Buffer size of 64 long words allocated to the channels, i.e. eight PCM frames can be stored before transmission, individual channel capacity programmable. 4. Receive Deformatter RD - HDLC frame, zero-bit deletion, flag detection, CRC checking, transparent mode reception and V.110, X.30 80 bit framing. 5. Receive Buffer RB - Buffer size of 64 long words allocated to the channels, i.e. eight PCM frames can be stored, individual long words are freely accessible by each channel. 6. Configuration and State RAM CSR - Since the Transmit Formatter, Receive Deformatter are used in a multiplex manner, the state and configuration information of each channel has to be stored. 7. DMA Controller CM - Interrupt processing, memory address calculation, chaining list handling, chip configuration. 8. P interface MI - Motorola/Intel microprocessor interface.
User's Manual
24
01.2000
PEB 20320
Introduction 1.6 System Integration
The MUNICH32 is designed to handle up to 32 data channels of a PCM highway. It transfers the data between the PCM highway and a memory shared with a host processor via a 32-bit P interface. At the same time it performs protocol formatting and deformatting as well as rate adaption for each channel independently. The host sets the operating mode, bit rate adaption method and time slot allocation of each channel by writing the information into the shared memory. Using subchanneling each time slot can be shared between up to four MUNICH32s; so that in one single time slot four different D-channels can be handled by four MUNICH32s. Figure 4, Figure 5 and Figure 6 give a general overview of system integration of the MUNICH32.
PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s)
0 Up to 4 MUNICH32 MUNICH32
HOLD HLDA
1 MUNICH32
HOLD HLDAO HLDA
2 MUNICH32
HOLD HLDAO HLDA
3 MUNICH32
HOLD HLDAO HLDA
CPU
HOLD HLDA
HLDA System Bus
HLDA
HLDA
HLDA
Memory
Optional CPU
ITS03489
Figure 4 General System Integration (Intel Bus Mode)
User's Manual
25
01.2000
PEB 20320
Introduction
PCM Highway (2.048 Mbit/s, 1.544 Mbit/s, 1.536 Mbit/s, 4.096 Mbit/s)
MUNICH32
MUNICH32
System Bus
Memory
CPU
ITS03490
Figure 5 General System Interface (Intel Bus Mode)
PCM Highway
BR BG BGACK
System Bus
Memory
Optional CPU
ITS03491
Figure 6 General System Interface (Motorola Bus Mode)
User's Manual 26 01.2000
BR BG BGACK
Up to 4 MUNICH32
MUNICH32
MUNICH32
HOLD HLDAO HLDA
CPU
HOLD
HLDA
PEB 20320
Introduction MUNICH32's bus interface consists of a 32 bit bidirectional data bus (D31 ... D0), 32/28 Address lines (A31 ... A2, BE3 ... BE0) or (A27 ... A2, BE3 ... BE0), four data byte parity lines DP(3:0), five lines (W/R/R/W, ADS/AS, DS/PCHK, BERR READY/DSACK) to control and monitor the bus cycle, one action request and one Interrupt line. The system bus allocation is controlled by the four signals (HOLD/BR, HLDA/BG, BGACK, HLDAO/BGO). A mode pin allows the bus interface to be configured for either Intel or Motorola mode. An operation mode pin B16 enables the transfer of a 32 bit long word in two consecutive 16 bit word operations. Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 illustrate how the MUNICH32 may be used in different applications, like in a Primary Rate Interface, a Router, a Packet Switch and a Central D-Channel Handler, as part of an ISDN switching system.
T1/S2 Line Line Interface FALC54 PEB 2254 PCM System Interface System Bus Interrupt Controller System Memory
INT/INT AR System Bus Controller Host Interface (Alternative B)
Local CPU Bus
MUNICH32 PEB 20320
CPU
Host Interface (Alternative A)
CPU Bus Arbitration
ITS07372
Figure 7 Architecture of a Primary Access Board
User's Manual 27 01.2000
PEB 20320
Introduction
PCM Highway
Signaling Highway
EPIC PEB 2056
R
Interrupt Controller
HSCX SAB 82525
System Memory
System Bus
INT/INT AR System Bus Controller Host Interface (Alternative B)
Local CPU Bus
MUNICH32 PEB 20320 PCM System Interface CPU Bus Arbitration
CPU
Host Interface (Alternative A)
ITS04829
Figure 8 Architecture of a Central D-Channel Handler
User's Manual
28
01.2000
PEB 20320
Introduction
T1/S2 Line Line Interface
V.24, V.21, V.35, ...
Line Driver FALC54 PEB 2254 Interrupt Controller ESCC8 SAB 82538 System Memory
System Bus
INT/INT AR
System Bus Controller
Local CPU Bus
PCM System Interface
MUNICH32 PEB 20320
CPU
CPU Bus Arbitration
ITS07374
Figure 9 Architecture of a Packet Switch/Router
User's Manual
29
01.2000
PEB 20320
Introduction
T1/S2 Line Line Interface FALC54 PEB 2254 PCM System Interface Interrupt Controller System Memory
System Bus
INT/INT AR Local CPU Bus
System Bus Controller
Local CPU Bus
MUNICH32 PEB 20320
CPU
(not compatible with Intel 386 or Motorola 68020)
CPU Bus Arbitration
CPU Bus Arbitration
ITS07371
Figure 10 MUNICH32 in a System with a RISC CPU Note: To reduce complexity the host interface is not explicitly shown here.
User's Manual
30
01.2000
PEB 20320
Introduction
T1/S2 Line Line Interface FALC54 PEB 2254 PCM System Interface Interrupt Controller System Memory
System Bus
INT/INT AR Local CPU Bus
System Bus Controller
Local CPU Bus
MUNICH32 PEB 20320
Multi Port RAM Controller
CPU
CPU Bus Arbitration
Multi Port Memory
CPU Bus Arbitration
ITS07373
Figure 11 MUNICH32 in a System using Multiport Memory Note: To reduce complexity the host interface is not explicitly shown here.
User's Manual
31
01.2000
PEB 20320
Functional Description 2 2.1 Functional Description Serial Interface
The serial interface of MUNICH32 includes a data receive (RDATA) and a data transmit line (TDATA) as well as the accompanying control signals (RCLK = Receive Clock, RSP = Receive Synchronization Pulse, TCLK = Transmit Clock, TSP = Transmit Synchronization Pulse). The timings of the receive and transmit PCM highway are independent of each other, i.e. the frame positions and clock phases are not correlated. Data is transmitted and received either at a rate of 2.048 Mbit/s for the CEPT 32-Channel European PCM format (Figure 14) or 1.544 Mbit/s or 1.536 Mbit/s for the T1/DS1 24-Channel American PCM format (Figure 12 and Figure 13). MUNICH32 may also be connected to a 4.096-Mbit/s PCM system (Figure 15), where it handles either the even- or odd-numbered time slots, so all 64 time slots can be covered by connecting two MUNICH32s to the PCM highway. The actual bit rate of a time slot can be varied from 64 Kbit/s down to 8 Kbit/s for the receive and transmit direction. A fill mask code specified in the time slot assignment determines the bit rate and which bits of a time slot should be ignored. Any of these time slots can be combined to a data channel allowing transmission rates from 8 Kbit/s up to 2.048 Mbit/s. The frame alignment is established by the transmit and receive synchronization pulse (TSP, RSP), respectively. The sampled rising edge of TSP identifies the current bit on the serial line (TDATA) as the last bit of a PCM frame. The sampled rising edge of RSP indicates that the current bit on the serial line (RDATA) is the first bit of a PCM frame. The F-bit for the 1.544 MHz T1/DS1 24-channel PCM format is ignored in receive direction, the corresponding bit is tristate in transmit direction. It is therefore assumed that this channel is handled by a different device. For test purposes four different test loops can be switched. In a complete loop all logical channels are mirrored either from serial data output to input (internal loop) or vice versa (external loop). In a channelwise loop one single logical channel is logically mirrored either from serial data output to input (internal loop) or vice versa (external loop). A detailed description of the different loops is found in Chapter 4.2.1 and Chapter 5.1.
User's Manual
32
01.2000
PEB 20320
Functional Description
125 s SLOT 0 SLOT 1 F0123456701234567 PCM - Frame SLOT 23 6 TCLK 7 F 0 1 2 SLOT 0 3 4 5 6 7 SLOT 1 SLOT 23
TSP
TDATA
FILL/MASK T1/DS1 - Mode Transmit Frame Timing
Fill/Mask : Slot 0 10011000
SLOT 23 6 RCLK 7 F 0 1 2
SLOT 0 3 4 5 6 7
SLOT 1
RSP
RDATA
DATA
DATA
DATA
DATA
DATA
DATA
FILL/MASK T1/DS1 - Mode Receive Frame Timing
Fill/Mask : Slot 0 11010110
ITD03496
Figure 12 T1/DS1 Mode PCM Frame Timing 1.544 MHz Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: The fill/mask bit for the F-bit is not defined. TDATA is tristate for the F-bit, and the F-bit is ignored in the receive direction. Note 3: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame.
User's Manual 33 01.2000
PEB 20320
Functional Description
125 s SLOT 0 SLOT 1 0123456701234567 PCM - Frame SLOT 23 6 TCLK 7 0 1 2 SLOT 0 3 4 5 6 7 SLOT 1 SLOT 23
TSP
TDATA
FILL/MASK T1/DS1 - Mode Transmit Frame Timing
Fill/Mask : Slot 0 10011000
SLOT 23 6 RCLK 7 0 1 2
SLOT 0 3 4 5 6 7
SLOT 1
RSP
RDATA
DATA
DATA
DATA
DATA
DATA
DATA
FILL/MASK T1/DS1 - Mode Receive Frame Timing
Fill/Mask : Slot 0 11010110
ITD03497
Figure 13 T1/DS1 Mode PCM Frame Timing 1.536 MHz Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame.
User's Manual 34 01.2000
PEB 20320
Functional Description
125 s SLOT 0 SLOT 1 0123456701234567 PCM - Frame SLOT 31 6 TCLK 7 0 1 2 SLOT 0 3 4 5 6 7 SLOT 1 SLOT 31
TSP
TDATA
FILL/MASK CEPT - Mode Transmit Frame Timing
Fill/Mask : Slot 0 10011000
SLOT 31 6 RCLK 7 0 1 2
SLOT 0 3 4 5 6 7
SLOT 1
RSP
RDATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
FILL/MASK CEPT - Mode PCM - Frame Timing
Fill/Mask : Slot 0 11010110
ITD03498
Figure 14 CEPT Mode PCM Frame Timing Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame.
User's Manual 35 01.2000
PEB 20320
Functional Description
125 s SLOT 0
01234567
SLOT 1
01234567
SLOT 31
01234567
TSP
RSP 4.096 Mbit/s PCM-format: even numbered slot allocation
SLOT 0
67 01234567
SLOT 31
01234567
TSP
RSP 4.096 Mbit/s PCM-format: odd numbered slot allocation
ITD03528
Figure 15 4.096 Mbit/s PCM Frame Timing Note 1: A box in a bit of the RDATA line means that this bit is ignored (HDLC, TMB, TMR, V.110/X.30) or received as `1'-bit (TMA; one overwrite). Note 2: TSP and RSP must have one single rising and falling edge during a 125 s PCM frame.
User's Manual 36 01.2000
PEB 20320
Functional Description
125 s 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 x 64 kbit/s 0 1 2 1 3 4 1 5 6 78791
ITD03499
Figure 16 Example: Programmable Channel Allocation for 32 Time Slots
125 s 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 x 64 kbit/s
0
1
2
3
4
3
5
1
2
6
ITD03500
Figure 17 Example: Programmable Channel Allocation for 24 Time Slots
User's Manual
37
01.2000
PEB 20320
Functional Description 2.2 Microprocessor Interface
A 64-channel DMA controller (32 channels in receive direction and 32 channels in transmit direction) with buffer chaining capability is integrated in the MUNICH32. It provides DMA functions for up to 32 full duplex channels and allows data transfer between the serial interface and an external memory. The MUNICH32 performs long word by long word transfers on a 32-bit bidirectional data bus (D(31:0)) and addresses up to 4 GByte of RAM with a 30-bit address bus (A(31:2)). The chip always works as a system bus master and can be operated in either a Intel or Motorola environment. MUNICH32 receives commands and data from the host processor via the shared memory. The host stores the action specification containing configuration initialization and monitor commands in the memory. Afterwards the host informs the MUNICH32 by generating an action request pulse (AR line). The MUNICH32 reacts by reading the action specification and informs the microprocessor by appending the respective interrupt information to the interrupt queue. In addition, the INT/INT line is activated during the write access belonging to the interrupt specification. The timing of the microprocessor interface is established according to the Intel 80386 or Motorola 68020 processor. The system clock (SCLK) provides the fundamental timing for the P interface and is the internal device clock. Each bus cycle performs a long word (B16 = 1) or a word (B16 = 0) transfer and takes four system clock periods in the fastest case, any number of wait clock cycles can be inserted. MUNICH32's architecture is based on a 32-bit data structure. Therefore MUNICH32 performs long word operations preferably. While the word operation mode is selected the long word operation is divided into two consecutive word operations. In the case of a read access the data of the two words are connected together to build a 32-bit long word before processing. Mode Intel Operation Mode B16 1 0 0 1 0 0 BE(3-0) 0H 3H CH 0H 8H AH Access long word MSB word LSB word long word MSB word LSB word
Motorola
For a read access first the MSB bytes of a long word will be transferred and then the LSB bytes via D(15:0). For a write access first the LSB-bytes of a long word will be transferred and then the MSB bytes via D(15:0). The signal B16 cannot be changed dynamically and should be set to `1' in Intel parity mode (parity mode is not available in 16-bit word Intel mode).
User's Manual
38
01.2000
PEB 20320
Functional Description 2.2.1 Intel Mode
The Intel mode has two submodes - parity mode (even parity) and non parity mode - to be chosen by strapping PM to `1' or `0' respectively. In Intel mode the lower (higher) ordered byte of a long word (D31 ... D0) is assigned to the lower (higher) ordered physical address. The read or write bus cycle is controlled by the signals W/R, ADS and READY as shown in Figure 18, Figure 19. Each bus cycle consists of two bus states (S1, S2). During state S1 the address signals and bus cycle definition signals are driven valid. Simultaneously, the address status ADS is asserted to indicate their availability. The bus cycles are terminated by asserting READY. READY is ignored on the first bus state S1 and sampled at the end of the following state S2. If READY is not asserted in S2 then wait cycles SW are inserted until a bus cycle end is detected. During a read cycle the MUNICH32 floats its data signals to allow external memory to drive the data bus. The input data and parity bits DP3-0 (if parity mode is selected) is latched when READY is asserted. During a write cycle MUNICH32 drives the data signals and parity bits DP3- 0 (if parity mode is selected) beginning in the second clock period of S1 until the first clock period following the cycle acknowledgment READY. If a bus cycle error indicated by BERR has occurred, the MUNICH32 terminates the bus cycle. In case of a read cycle in the control and configuration section an action request fail interrupt is generated and the action is suspended. In case of a read cycle in the transmit data section the corresponding frame is aborted and a FO interrupt is generated. In all other cases of read or write cycles terminated with an error condition no actions are performed. A 4-bit data byte parity bus DP3-0 is used in Intel mode if parity mode is selected by strapping PM to `1'. During a read access DP3-0 is supposed to contain the parity of D(31:24), D(23:16), D(15:8) and D(7:0) respectively. A low active output PCHK indicates whether the parity was correct (PCHK = 1) or wrong (PCHK = 0) in the clock cycle after the data/parity is latched. PCHK stays low 1 or 2 clock cycles. No further action is taken as consequence to a parity fail. As the memory access is performed by using one common system bus, bus management is done with the signals HOLD, HLDA and HLDAO as shown in Figure 20. The wired or HOLD line is driven high whenever one of the MUNICH32s has to perform a bus transfer. The activated HOLD ACKNOWLEDGE indicates that the bus control will be released. If the specific device has activated the HOLD itself, it will start the memory access. Otherwise it will pass the signal to the next cascaded device. Several memory accesses may be required if the MUNICH32 has not been granted access recently. In this example of four MUNICH32 devices sharing the same bus, each device will generate four memory cycles, giving a total of 16 cycles per HOLD/HLDA/HLDAO tenure. In order to prevent blocking in the case of continuous request by one device, the MUNICH32 does not generate another HOLD REQUEST before the HOLD ACKNOWLEDGE has been deactivated.
User's Manual
39
01.2000
PEB 20320
Functional Description If the HOLD ACKNOWLEDGE is driven low while the MUNICH32 is performing a bus cycle, the bus is released later than two clock periods after de-assertion of HOLD ACKNOWLEDGE. The current bus cycle is finished with a bus cycle error. This action should be followed by an ASP.RES as described in Chapter 4.2.1.
S1 SCLK A31-A2 BE(3:0) [A27-A2] W/R ADS READY BERR [DP3-DP0], D(31:0) [PCHK]
READ
S2
S1
READ
S2
SW
SW
S1
BERR
S2
Tristate
ITD03501
Figure 18 Read Cycle Timing Diagram (Intel mode)
User's Manual
40
01.2000
PEB 20320
Functional Description
WRITE SCLK A31-A2 BE(3:0) [A27-A2] W/R ADS READY BERR [DP3-DP0], D(31:0) INT [PCHK]
WRITE
BERR
Tristate
ITD03502
Figure 19 Write Cycle Timing Diagram (Intel mode)
User's Manual
41
01.2000
PEB 20320
Functional Description
MUNICH32 gets the Bus
Another Bus Master gets the Bus
No Bus requests
HOLD (extern)
Tristate
~ ~
SCLK
Tristate
HOLD (intern)
Tristate
Tristate
HLDA
HLDAO Bus Cycle Max. 4 Clock Periods
ITD03503
Figure 20 Bus Management for Intel Bus Mode Note 1: Bus Cycle means, that the MUNICH32 under consideration starts a read or write access at most 4 clock periods after HLDA is asserted after its HOLD. The MUNICH32 terminates the cycle typically two clock periods after the last bus cycle. Note 2: In the Bus Management example it is assumed that the MUNICH32 under consideration has a higher priority than the other bus master. HOLD (internal) is therefore the internal request generated by the MUNICH32, HOLD (external) the signal on the external HOLD line, being the OR combination of the HOLD signal generated by the MUNICH32 and the other bus master(s). Note 3: A typical configuration example for a system with several bus masters is given in Figure 4 and Figure 5.
User's Manual
~ ~
42
01.2000
PEB 20320
Functional Description 2.2.2 Motorola Mode
In Motorola mode the bus is used in an asynchronous manner. The bus operation uses the handshake lines (AS, DS, DSACK and BERR) to control data transfer as shown in Figure 21, Figure 22. Address strobe AS indicates the validity of an address on the address bus (A31 ... A2) and of the bus definition R/W (Read or Write cycle). It is asserted half a clock cycle after the beginning of a bus cycle. The data strobe DS signal is used as a condition for valid data of a write cycle. MUNICH32 asserts DS one full clock cycle after the assertion of AS during a write cycle. The data is placed on the bidirectional data bus (D31 ... D0) half a clock cycle after AS is driven low. For a read cycle, MUNICH32 asserts DS to signal the external memory to drive the data on the bus. DS is asserted at the same time as AS during a read cycle. The data is latched with the last falling edge of the clock for that cycle. The bus cycle is terminated if the data transfer acknowledge (DSACK) is asserted with the falling edge of the third clock period. Otherwise MUNICH32 inserts wait cycles until DSACK is recognized. AS and DS are driven high half a clock period before bus cycle end. The bus error BERR is also a bus cycle termination indicator. It can be used in the absence as well as in conjunction with DSACK. If an abnormal termination has occurred during a read cycle, MUNICH32 generates an interrupt and aborts the corresponding transmit channel. For a write cycle no further action is performed. As the MUNICH32 is used in a multi-bus-master application, bus arbitration has to be done to avoid simultaneous system bus access by more than one master. In Motorola mode the bus arbitration protocol of the 68020 is established using the signals BR, BG, BGACK and BGO as shown in Figure 23. The wired-or Bus Request (BR) is driven low to indicate to the processor that one of the MUNICH32s requires control of the bus. The activated Bus Grant (BG) signals the availability of the system bus. If the MUNICH32 has activated the bus request itself, it asserts the wired-or Bus Grant Acknowledge to indicate that it has assumed bus mastership. Otherwise it will pass the BUS GRANT signal to the device cascaded next (BGO). At the same time it releases the Bus Request. After finishing the last bus cycle, the Bus Grant Acknowledge is deactivated and the Bus Grant is passed on. In order to prevent blocking in the case of continuous request by one device, MUNICH32 does not generate another Bus Request before the external Bus Request and Bus Grant Acknowledge have been deactivated. After getting the bus mastership MUNICH32 drives the bus and starts the first bus cycle one clock after assertion of BGACK. After finishing the memory access it releases the bus and de-asserts BGACK at the same time.
User's Manual
43
01.2000
PEB 20320
Functional Description
READ SCLK A31-A2, BE (3:0) R/W AS DS DSACK D (31:0) BERR
READ
BERR
Tristate
ITD03504
Figure 21 Read Bus Cycle Timing Diagram for Motorola Bus Mode
WRITE SCLK A31-A2, BE (3:0) R/W AS DS DSACK D (31:0) BERR INT
ITD03505
WRITE
BERR
Tristate
Figure 22 Write Bus Cycle Timing Diagram for Motorola Bus Mode
User's Manual 44 01.2000
PEB 20320
Functional Description
MUNICH32 gets the Bus Max. 4 Clock Periods
Another Bus Master gets the Bus
No Bus requests
BR (extern)
BR (intern)
BGACK (extern)
BGACK (intern)
BGO
ITD03506
Figure 23 Bus Management for Motorola Mode Note: 1. In the Bus Management example it is assumed that the MUNICH32 under consideration has a higher priority than the other bus master. BR and BGACK are wired AND lines to be pulled to `1' by an external signal. 2. A typical configuration example for a system with several bus masters is given in Figure 6.
User's Manual
~ ~
BG
~ ~
SCLK
45
01.2000
PEB 20320
Functional Description 2.2.3 DMA Priorities
Prioritization of Queueing DMA Cycles Priority Highest priority Lowest priority Interrupt Receive link list including accesses to the descriptors Transmit link list including accesses to the descriptors Configuration of a channel (action requests)
The MUNICH32 will perform all pending accesses on the same bus tenure. Note: Several bus transactions may be required if the MUNICH32 has not been given access to the system bus for a long period of time. This is often seen in multimaster systems where several MUNICH32 devices share the system bus.
User's Manual
46
01.2000
PEB 20320
Functional Description 2.3 Basic Functional Principles
MUNICH32 is a Multichannel Network Interface Controller for HDLC, offering a variety of additional features like subchanneling, data channels comprising of one or more time slots, DMI 0, 1, 2 transparent or V.110/X.30 transmission and programmable rate adaption. MUNICH32 performs formatting and deformatting operations in any network configuration, where it implements, together with a microprocessor and a shared memory, the bit oriented part (flag, bit stuffing, CRC check) of the layer 2 (data link protocol level) functions of the OSI reference model. The block diagram is shown in Figure 3. MUNICH32 is designed to handle up to 32 data channels of a 1.536/1.544 Mbit/s T1/DS1 24-channel, 2.048-Mbit/s CEPT 32-channel or a 4.096-Mbit/s 32-channel PCM highway. The device provides transmission for all bit rates from 8 Kbit/s up to 2.048 Mbit/s of packed data in HDLC format or of data in a transparent format supporting the DMI mode (0, 1, 2) or V.110/X.30 mode. Tristating of the transmission line as well as switching a channelwise or complete loop are also possible. An on-chip 64-channel DMA generator controls the exchange of data and channel control information between the MUNICH32 and the external memory. The MUNICH32 processes receive and transmit data independently for each time slot and transmission direction respectively (blocks TF = Transmit Formatter, RD = Receive Deformatter). The frame counters are reset by the rising edges of the RSP or TSP line. The processing units TF and RD work with a multiplex management, i.e. there exists only one protocol handler, which is used by all channels in a time sharing manner (see Figure 24 and Figure 25). The actual configuration, e.g. transmission mode, channel assignment, fill/mask code or state of the protocol handlers is retrieved from the Configuration and State RAM (CSR) at the beginning of the time slot and reloaded to the CSR at the end. The control unit (CD) controls the access to the CSR and allows writing of reconfiguration information only if the continuous transfer of the configuration information between the CSR and the formatters (TF and RD) will not be disturbed. In receive direction, 32 unpacked data bits are first accumulated and then stored into an on-chip receive buffer (RB) for transfer to the shared memory. As soon as the RB receives 32 bits for a channel it requests access to the parallel microprocessor bus. The on-chip transmit buffer (TB) is always kept full of data ready for transmission. The TB will request more data when 32 bits become available in the ITBS. These buffers allows a flexible access to the shared memory in order to prevent data underflow (Tx) and data overflow (Rc). The transmit buffer (TB) has a size of 64 long words (= 256 bytes). In this buffer, data of 8 PCM frames can be stored for each data channel. In this case, there are max. 1 ms between access to the shared memory and data supply to the Transmit Formatter. In order to meet these requirements a variable and programmable part of the buffer (ITBS) must be allocated to each data channel (see Figure 26).
User's Manual
47
01.2000
Active Receive Channel (external) SCLK Active Receive Channel (internal)
X1
X2
~ ~ ~ ~
RCLK
~ ~ ~ ~
X0
~ ~
~ ~
...
User's Manual 48 01.2000
Figure 24 Multiplex Management Receive Direction
RDATA
Bit 0
Bit 1
Bit 2
Bit 7
Bit 0
Bit 1
X3
X1
X2
Load CD, CSR Data for X 1 into RD RD Protocol Operation disabled RDATA
Protocol Operation Phase of RD, CM might write new Channel Config Data into CSR
Wait Phase no Operation of RD, CM might write new Channel Config Data into CSR
Reload RD into CSR Protocol Operation disabled
Load CSR Data for X 2 into RD RD Protocol Operation disabled RDATA
CD CSR
X1
CSR
RD
CSR CSR
X1
CD
Functional Description
CSR
X2
RD
CM
FIFO
CM
RD
RD
ITD04397
PEB 20320
TDATA
~~ ~~ ~~ ~~
Active Transmit Channel (external)
~ ~
~ ~ ~ ~
SCLK Active Transmit Channel (internal)
X0
~ ~
...
User's Manual 49 01.2000
Figure 25 Multiplex Management Transmit Direction
Bit 7
Bit 0
Bit 1
Bit 6
Bit 7
Bit 0
TCLK
X0
X1
X1
X2
Load CSR Data for X 1 into TF TF Protocol Operation disabled
Protocol Operation Phase of TF, CM might write new Channel Config Data into CSR
Wait Phase no Operation of TF CM might write new Channel Config Data into CSR
Reload TF into CSR, CD TF Protocol Operation disabled TDATA
CSR CSR
X1
TF
CSR CSR
X1
CD
Functional Description
TF
CM
X1 X2 X0
FIFO
CM
TF
ITD04398
PEB 20320
PEB 20320
Functional Description For example: a) 2.048-Mbit/s PCM highway 32 x 64-Kbit/s data channels (8 bits are sent with each PCM frame). Two long words of the buffer are allocated to each data channel. b) 1 x 2.048-Kbit/s data channel The maximum buffer size for one channel (63 long words) is allocated to this data channel. c) 6 x 256-Kbit/s and 8 x 64 Kbit/s data channels. Eight long words of the buffer are allocated to each of the 6 data channels with 256 Kbit/s and two long words are assigned to each of the 8 data channels with a transmission rate of 64 Kbit/s. The choice of the individual buffer size of each data channel can be made in the channel specification (shared memory). The buffer size of one channel is changeable without disturbing the transmission of the other channels.
CD
Active Transmit Channel (internal)
Used as Address Offset for TB
TF
Unused ITBS of Channel ITBS of Channel TB ITBS of Channel ITBS of Channel X1 X0 X2 X3
ITD04396
64 Long Words
Figure 26 Partitioning of TB
User's Manual 50 01.2000
PEB 20320
Functional Description The receive buffer (RB) is a FIFO buffer and also has a size of 64 long words, which allows storing the data of eight complete PCM frames before transferring to the shared memory.
CD
Stored in RB together with Data/Status Word from RD
Active Receive Channel (internal)
RD
RB
64 Long Words
ITD04447
Figure 27 Partitioning of RB The data transfer to the shared memory is performed via a 32-bit microprocessor interface working either in SIEMENS/Intel or Motorola bus mode. Figure 28 shows the division of the shared memory required for each MUNICH32: - - - - Configuration start address located at a programmable address Control and configuration section An interrupt circular queue with variable size Descriptor and data sections for each channel.
User's Manual
51
01.2000
PEB 20320
Functional Description
Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor
Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor Receive DATA Receive Descriptor Transmit DATA Transmit Descriptor
Interrupt Queue Receive Descriptor Transmit Descriptor
ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec.
CI(4:0) Control Start Address Control and Configuration section
Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 Interrupt Queue Receive Descriptor Transmit Descriptor Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 Interrupt Queue Receive Descriptor Transmit Descriptor Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 Interrupt Queue Receive Descriptor Transmit Descriptor Channel 31 spec. Current Receive Descriptor Address 0 ... 31 Current Transmit Descriptor Address 0 ... 31 ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec. CI(4:0) Control Start Address Control and Configuration section ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec. CI(4:0) Control Start Address Control and Configuration section ACTION SPEC. INTERRUPT QUEUE Spec. Time-Slot Assignment Channel 0 spec. CI(4:0) Control Start Address Control and Configuration section
ITD03507
Figure 28 Memory Division for up to four MUNICH32
User's Manual 52 01.2000
PEB 20320
Functional Description The shared memory allocated for each transmit and receive channel is organized as a chaining list of buffers set up by the host. Each chaining list is composed of descriptors and data sections. The descriptor contains the pointer to the next descriptor, the start address and the size of a data section. It also includes control information like frame end indication, transmission hold and rate adaption with interframe time-fill. In the transmit direction the MUNICH32 reads a transmit descriptor, calculates the data address, writes the current transmit descriptor address into the CCS, and fills the on-chip transmit buffer. When the data transfer of the specified section is completed, the MUNICH32 releases the buffer, and branches to the next transmit descriptor. If a frame end is indicated the HDLC, TMB or TMR frame will be terminated and a specified number of the interframe time-fill byte will be sent in order to perform rate adaption. If frame end is found in a transmit descriptor TMA channel the specified number of programmable TMA flags is appended to the data in the descriptor. If frame end is found in a transmit descriptor of a V.110/X.30 channel the frame is aborted (after the data in the descriptor are sent) by finishing the current 10-octet frame with `zeros' and sending 2 more 10-octet frames with `zeros' which leads to a loss of synchronism on the peer side. An adjustment for the inserted zeros in HDLC is programmable, which leads to a reduction of the specified number of interframe time-fill by 1/8th of the number of zero insertions. This can be used to send long HDLC frames with a more or less fixed data rate in spite of the zero insertions. A maskable interrupt is generated before transmission is started again.
User's Manual
53
01.2000
PEB 20320
Functional Description The following Sections give Examples of Typical Transmit Situations for the Individual Modes Variable Size Frame Oriented Protocols (HDLC, TMB, TMR) Normal operation, handling of frame end (FE) indication and hold (H) indication. Note: 1. FNUM0 must be set to zero. 2. Flag = 7EH for HDLC 00H for TMB, TMR IC = 7EH for HDLC and IFTF = 0 FFH for HDLC and IFTF = 1 00H for TMB, TMR 3. After sending the FNUM2 - 1 IC characters the device starts polling the hold bit in the transmit descriptor once for each further sent IC character. It also rereads the pointer to the next transmit descriptor once with each poll of the hold indication. The pointer to the next transmit descriptor can be changed while HOLD = 1 is set. The value of the pointer, (read in the poll where HOLD = 0) is used as the next descriptor address. If more than 6 IC characters will be sent, the use of the Transmit Hold (TH) should be considered as an alternative to using the descriptor hold bit. See Chapter 5.3.2.
User's Manual
54
01.2000
Figure 29
Flag, C, ... , C Flag Frame ( Data 3 ) Frame ( Data 4 ) FNUM2 Flag, C , C C, C , C , C , Flag FNUM1+1
User's Manual
... ...
Poll H=1? Poll H=0
Flag
Frame (Data 1, Data 2)
...
...
...
FE=0 FNUM0 H =0
FE = 1 FNUM1 H =0
FE =1 FNUM2 H =1
Transmit Descriptors Next Transmit Descr.
55
Next Transmit Descr.
Next Transmit Descr.
....
Data 1
Data 2
Data 3
Data 4
Data Sections
ITD04446
PEB 20320
Functional Description
01.2000
PEB 20320
Functional Description Fixed Size Frame Oriented Protocols (V110/X.30) Normal operation, E, S, X change (indicated by the V.110-bit in the transmit descriptor) Example for TRV = `11' Note: 1. FNUM must be 0 for all transmit descriptors. 2. The actual E-, S-, X-bits have to be in the first transmit descriptor after reset. 3. As shown in the example the contiguous parts of a data section belonging to one descriptor are sent in contiguous frames (DATA 1(1) are the bytes 0 - 3 of DATA 1, DATA 1(2) are the bytes 4 - 7 of DATA 1). If the end of a data section is reached within a frame, the frame is continued with data from the next data section belonging to a transmit descriptor with the bit V.110 = 0 (DATA 2(2) = byte 4 of DATA 2, DATA 3(1) = byte 0 - 2 of DATA 3). 4. The E-, S-, X-bits are only changed from one frame to the next not within a frame. The change occurs in the first frame which does not contain data of the previous data section. 5. Neither FE nor H may be set to 1 during a normal operation of the mode. They both lead to an abort of the serial interface.
User's Manual
56
01.2000
Figure 30
Frame ( E, S, X, Data 1 (2) ) 10 Octets 10 Octets 10 Octets 10 Octets Frame ( E, S, X, Data 2 (1) ) Frame ( E, S, X, Data 2, (2) Data 3 (1) ) Frame ( E, S, X, Data 3(2) )
User's Manual
...00
Frame ( E, S, X, Data 1 (1) )
...
10 Octets
FE=0 H =0 FE = 0 NO=9 H =0 V110 = 0
NO=2
FE = 0 NO=8 H =0 V110 = 0 FE=0 NO = 5 H =0 V110 = 0 FE = 0 NO=2 H =0 V110 = 1
57
Next Transmit Descr. Next Transmit Descr. Next Transmit Descr. Data 1 E, S, X, Data 2 Data 3
Transmit V110=1 Descriptors Next Transmit Descr.
Next Transmit Descr.
.....
E, S, X,
Data Sections
ITD04444
PEB 20320
Functional Description
01.2000
PEB 20320
Functional Description Fixed Size Frame Oriented Protocols (V.110/X.30) Handling of frame end (FE) indication Note: 1. FNUM must be `0' for all transmit descriptors. 2. The frame (E, S, X, DATA 2(2)) is the beginning of a 10-octet frame. It stops with the octet no. y, containing the last data bit of DATA 2 to be sent. 3. Since y = 1, ..., 10 the 20 + y times 00H characters sent afterwards cause the peer station to recognize 3 consecutive 10-octet frames with frame error which leads to a loss of synchronism in the peer station. 4. For y = 10 DATA 2 is identical to DATA 2(1) and 30 times 00H characters are sent after frame (E, S, X, DATA 1(2), DATA 2(1)). 5. The E-, S-, X-bits are supposed to be loaded by an earlier transmit descriptor in the example. A descriptor changing them (with V.110-bit set) can be put between, before or after the descriptors in the example. It will change these bits according to the rules discussed previously.
User's Manual
58
01.2000
Figure 31
User's Manual
(1)
...
) Frame ( E, S, X, Data 1 , Data 2 10 Octets y=1,...,10 10-y Octets 10 Octets 20+y Octets
(2) (1)
Frame ( E, S, X, Data 1
) Frame ( E, S, X, Data 2
(2)
)
00,......,00 Frame ( E, S, X, Data 3
(1)
)...
10 Octets
Transmit V110 = 0 Descriptors
FE=0 H =0
FE = 1 H =0 V110 = 0
FE=0 H =0 V110 = 0
59
....
Data 1
Data 2
Data 3
Data Sections
ITD04448
PEB 20320
Functional Description
01.2000
Figure 32
00,......,00 00 00 10 Octets 20+y Octets ... 00 00 Frame ( E, S, X, Data 3 (1) ) . . . 10 Octets y=1,...,10 Poll H=1? Poll H=0 10-y Octets
FE=0 H =0 V110 = 0
User's Manual
...
Frame ( E, S, X, Data 1
(1)
(2) (1) (2) ) Frame ( E, S, X, Data 1 , Data 2 ) Frame ( E, S, X, Data 2 )
Handling of hold (H) indication
10 Octets
Fixed Size Frame Oriented Protocols (V110/X.30)
Transmit V110 = 0 Descriptors
FE=0 H =0
FE = 1 H =1 V110 = 0
60
....
Data 1
Data 2
Data 3
Data Sections
ITD04449
PEB 20320
Functional Description
01.2000
PEB 20320
Functional Description Time Slot Oriented Protocol (TMA) Normal operation, handling of frame end (FE) indication and hold (H) indication. Note: 1. FNUM must be set to zero. 2. TC = FFH for TMA and FA = 0 the programmed flag with TMA and FA = 1 3. After sending the FNUM2 - 1 IC characters the device starts polling the hold bit in the transmit descriptor once for each further sent IC character. It also rereads the pointer to the next transmit descriptor once with each poll of the hold indication. The pointer to the next transmit descriptor can be changed while HOLD = 1 is set. The value of the pointer, (read in the poll where HOLD = 0) is used as the next descriptor address. If more than 6 IC characters will be sent, the use of the Transmit Hold (TH) should be considered as an alternative to using the descriptor hold bit. See Chapter 5.3.2.
User's Manual
61
01.2000
Figure 33
...
TC,..................,TC Data 3 Data 4 FNUM2 TC, TC, TC,........TC, TC FNUM1+1 TC, TC,.............TC,
User's Manual
Time-Slot Boundaries
... ...
...
...
...
... ...
Poll H=1? Poll H=0
TC
Data 1
Data 2
FE=0 FNUM0 H =0
FE = 1 FNUM1 H =0
FE=1 FNUM2 H =1
62
Next Transmit Descr.
Transmit Descriptors
Next Transmit Descr.
Next Transmit Descr.
....
Data 1
Data 2
Data 3
Data 4
Data Sections
ITD04445
PEB 20320
Functional Description
01.2000
PEB 20320
Functional Description An activated transmission hold (hold bit in descriptor) prevents the MUNICH32 from sending more data. If a frame end has not occurred just before, the current frame will be aborted and an interrupt generated. Afterwards, the interframe time-fill bytes will be issued until the transmission hold indication is cleared. There is a further transmit hold (TH) bit in the Channel Specification (CCS) in addition to the hold bit in the descriptor. Setting the transmit hold (TH) bit by issuing a channel command will prevent further polling of the transmit descriptor (see Chapter 5.3.2). This hold bit (CCS.TH) is interpreted in the CD; it causes the transmit formatter to stay in the idle state and to send interframe time-fill after finishing the current frame. In the case of a very short frame (< ITBS), this frame will stay in the TF and not be sent until CCS.TH is removed. (In case of X.30/V.110 the current frame is aborted). This means that the buffer TB is not emptied from the TF side after the current frame, but still requests further data from the shared memory until it is filled. In the case of the descriptor hold on the other hand, the TF empties the TB and there are no further data requests from the shared memory until the descriptor hold is withdrawn. Then TB is filled again and the TF is activated only after enough data are provided in the TB to prevent a data underrun. The Reaction to the Transmit Hold Bit is now Discussed for the Different Modes in the Following Sections Variable Size Frame Oriented Protocols (HDLC, TMB, TMR) Reaction to a channel specification containing TH = 1 Normal operation Note: 1. IC = 7EH for HDLC and IFTF = 1 FFH for HDLC and IFTF = 0 00H for TMB or TMR 2. flag = 7EH for HDLC 00H for TMB or TMR 3. FNUM2 is ignored. The number of interframe time-fills sent between the first frame and the second frame solely depends on the AR low pulse leading to the action with the channel with TH = 0. 4. The times t1 and t2 are statistical but typically only a few clock cycles. 5. The TH bit (as all channel commands) is not synchronized with TB! (as opposed to the H-bit in the descriptor) TH acts on the frame currently being sent, not necessarily on the last frame currently stored in the TB. In the example, TB may or may not have stored DATA 3 before the action request with TH = 1 was issued. See Chapter 4.2.5 for a further discussion of this issue. 6. If TH is handed over to CD outside of a frame, TH = 1 prevents the MUNICH32 from sending the next frame.
User's Manual 63 01.2000
User's Manual 64 01.2000
Figure 34
AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD
....
Flag Frame ( ..., Data 1 , Data 2 ) Flag, C,
....
C, Flag Frame ( Data 3 ) . . .
...
FE=0 H =0
FE = 1 FNUM2 H =0
....
Functional Description
Data 1
Data 2
Data 3
PEB 20320
ITD04450
PEB 20320
Functional Description Fixed Size Frame Oriented Protocol (V.110/X.30) Reaction to a channel specification containing TH = 1 Normal operation Note: 1. The times t1 and t2 are statistical but typically only a few clock cycles. 2. The current frame processed, when TH = 1 is handed over to CD is aborted, only 10 - y, (y = 1, ..., 10) octets of it are sent. The device then starts to send 20 + y 00H characters no matter how fast the TH bit is withdrawn. This ensures, that the peer site is informed about the abort with a loss of synchronism 3. The data section DATA 1 is split in the example; DATA 1(1) is sent in the aborted frame, all bits that were read into the MUNICH32 with the same access are discarded (they would have been sent in the next frame(s) if TH = 1 was not issued) and the device starts the next frame with the bits DATA 1(3) of the access to DATA 1 that follows the one getting the bits of DATA 1(1). 4. The TH (as all channel commands) is not synchronized with TB. TH acts on the frame currently sent, not necessarily on the last stored data. 5. If TH is handed over to CD before a frame has started after an abort or after reset no frame will start.
User's Manual
65
01.2000
PEB 20320
Functional Description
AR t1 TH=1 in the Channel Specificaton handed over from CM to CD 00 ... 00 ........... 20+y Octets t 2 TH=0 in the Channel Specificaton handed over from CM to CD 00 ... 00 Frame ( E, S, X, Data 1 (3) ) . . . 10 Octets
... Frame ( E, S, X, Data 1 (1) )
10-y Octets
...
FE=0 H =0
....
Data 1
ITD04454
Figure 35 Time Slot Oriented Protocol (TMA) Reaction to a channel specification containing TH = 1 Note: 1. TC is the programmed TFLAG for FA = 1 FFH for FA = 0 2. The times t1 and t2 are statistical but typically only a few clock cycles. 3. The TH bit (as all channel commands) is not synchronized with the TB! (as opposed to the H-bit in the descriptor) TH acts to the data stream currently sent.
User's Manual
66
01.2000
User's Manual 67 01.2000
Figure 36
AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD Time-Slot Boundaries Data 1 , Data 2 , TC,
....
TC, TC, TC, Data 3 . . .
FE=0 FNUM0 H =0
FE = 1 H =0
... ....
Functional Description
Data 1
Data 2
Data 3
PEB 20320
ITD04452
PEB 20320
Functional Description Variable Size Frame Oriented Modes (HDLC, TMB, TMR) Reaction to a channel specification containing TH = 1 Silencing of poll cycles for hold. Note: An AR pulse for an action specification leading to TH = 1 should be issued after (ITBS + 2) polls of the MUNICH32, where ITBS is the previously programmed number of long words in the TB reserved for this channel.
User's Manual
68
01.2000
User's Manual 69 01.2000
Figure 37
AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD
....
Flag Frame ( ..., Data 1 ) Flag, C, ... , C, FNUM0 Poll H=1? C, ... C, ... No Poll Poll H=1?
....
C, C, C , ... C, Flag Frame ( Data 2 ) . . . ... Poll H=0
...
FE=1 FNUM0 H =1
....
Functional Description
Data 1
Data 2
PEB 20320
ITD04451
PEB 20320
Functional Description Fixed Size Frame Oriented Protocol (V110/.30) Silencing of poll cycles by TH = 1 Note: 1. The times t1 and t2 are statistical but typically only a few clock cycles. 2. The TH bit (as all channel commands) is not synchronized with TB! (as opposed to the H-bit in the descriptor) TH acts to the data stream currently sent. 3. In the example the proper use to silence a channel polling the HOLD bit of the transmit descriptor is illustrated. The AR pulse is issued after the polling has started and the H-bit is not reset before polling has stopped by the TH bit. 4. An AR pulse for an action specification leading to TH = 1 should be issued after (ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed number of long words in the TB reserved for this channel.
User's Manual
70
01.2000
User's Manual 71 01.2000
Figure 38
AR t 1 TH=1 in the Channel Specif. handed over to CD ........... t 2 TH=0 in the Channel Specif. handed over from CM to CD 00 ... 00 Frame ( E, S, X, Data 2 (1) ) . . . 10 Octets Poll H=1 H=1 No Poll Poll H=1 H=0 Frame ( E, S, X, Data 1 (1) ) Frame ( E, S, X, Data 1 (2) ) 10 Octets 10-y Octets 00 ... 00 20+y Octets
...
FE=1 H =1
....
Functional Description
Data 1
Data 2
PEB 20320
ITD04455
PEB 20320
Functional Description Time Slot Oriented Protocol (TMA) Reaction to a channel specification containing TH = 1 Note: 1. TC = FFH for TMA and FA = 0 the programmed flag for TMA and FA = 1 2. FNUM2 is ignored. The number of interframe time-fills between the first frame and the second frame solely depends on the AR low pulse leading to the action with the channel with TH = 0. 3. The times t1 and t2 are statistical but typically only a few clock cycles. 4. The TH bit (as all channel commands) is not synchronized with TB (as opposed to the H-bit in the descriptor) TH acts on the data stream currently sent not necessarily on the last data stored in TB. In the example TB may or may not have stored DATA 3 before action request with TH = 1 was issued. 5. The data stream is stopped and TC sent after the last byte of DATA 2 is sent. The stopping is triggered by the FE = 1 bit in the descriptor. 6. If TH is bonded over to CD during interframe time-fill (TC) it prevents the MUNICH32 from sending further data afterwards. 7. An AR pulse for an action specification leading to TH = 1 should be issued after (ITBS + 2) polls of the MUNICH32, where ITBS is previously programmed number of long words in the TB reserved for this channel.
User's Manual
72
01.2000
User's Manual 73 01.2000
Figure 39
AR t1 TH=1 in the Channel Specification handed over from CM to CD t2 TH=0 in the Channel Specification handed over from CM to CD
....
... Data 1 , TC, TC, ... , TC, TC, FNUM0 Poll H=1? ... TC, ... No Poll Poll H=1?
....
TC, TC, TC , ... TC, ... Poll H=0
Data 2 . . .
...
FE=1 FNUM0 H =1
....
Functional Description
Data 1
Data 2
PEB 20320
ITD04453
PEB 20320
Functional Description In receive direction the MUNICH32 reads a receive descriptor, calculates the data address, writes the current receive descriptor address into the CCS, and exchanges data between the on-chip receive buffer and the external memory. After the data section has been filled, the MUNICH32 writes the number of stored bytes (BNO) into the descriptor. If a frame end has occurred the frame status is written into the descriptor and an interrupt is generated. The frame status includes the CRC check results and transmission error information like `non octet of bits', `aborted frame', `data overflow', `maximum frame length exceeded' and `frames with less than or equal to two data bytes'. An activated reception-hold in the descriptor prevents the MUNICH32 from processing the receive data. The incoming frames are discarded until the hold is deactivated. Because the MUNICH32 is divided into two non-synchronized parts by the on-chip buffers, two different kinds of aborting a channel transmission are implemented. - Normal abort: This abort of a receive or transmit channel is processed in the formatters of the serial interface. The interframe time-fill code is sent after aborting the current issued frame. No accesses to the on-chip buffers are carried out, until the abort is withdrawn. The handling of the link lists and the processing of the buffers by the DMA controller are not affected by normal abort. - Fast abort: A fast abort is performed by the DMA controller and does not disturb the transmission on the serial interface. If this abort is detected the current descriptor is suspended with an abort status immediately followed by a branching to the new descriptor defined in the channel specification of the CCS. For initialization and control the host sets up a Control and Configuration Section (CCS), including the action specification, interrupt queue specification, time slot assignment and the channel specification. The host initiates an action, e.g. reconfiguration, change of the channel mode, reset or switching of a test loop by updating the CCS and issuing an action request pulse. When the action request pulse is detected by the MUNICH32 it reads the control start address, then the action specification and, if necessary, additional information from the CCS. After execution, the action request is acknowledged by an interrupt. MUNICH32 indicates an interrupt by activating the interrupt line and storing the interrupt information including the corresponding channel number in the interrupt queue. The interrupt queue is a circular buffer; MUNICH32 starts to write the interrupt queue specification and fills it successively in a circular manner. The host has to allocate sufficient buffer size and to empty the buffer fast enough in order to prevent overflow of the queue.
User's Manual
74
01.2000
PEB 20320
Functional Description Monitoring functions are implemented in MUNICH32 to discover errors or condition changes, i.e. - Receive frame end - Receive frame abort by overflow of the receive buffer or hold condition or recognized ABORT flag - Frame overflow, if a frame has to be discarded because of pending inaccessibility of the chip memory - Transmit frame end - Transmit frame abort (data underrun) by underrun of the transmit buffer or hold condition or bus cycle error - Change of the interframe time-fill. - Loss of synchronism or change of framing bits (V.110, X.30). - Short frame with no data content detected. An error or condition change is indicated by an interrupt. The host may react to the interrupt by either aborting or tristating the specific channel or with a channel reconfiguration. To prevent underrun of the transmit buffer sufficient buffer size has to be allocated to the channel. A more detailed discussion of the receive procedure with examples is provided under the detailed protocol description in Chapter 2.4.
User's Manual
75
01.2000
PEB 20320
Functional Description 2.4 Detailed Protocol Description
In the following sections the protocol support of the MUNICH32 is described in detail for transmit and receive direction separately. Each section starts with a discussion of the general features proceeds with protocol variants and options from the channel specification and closes with a description of the interrupts and special topics. HDLC Transmit Direction General Features In transmit direction - - - - the starting and ending flag (7EH before and after a frame) the interframe time-fill between frames the zero insertions (a `0'-bit after 5 consecutive `1's inserted within a frame) (optional) the Frame Check Sequence (FCS) at the end of a frame
is generated automatically. Options The different options for this mode are - the kind of the interframe time-fill character in the channel specification - 7EH for IFTF = 0 - FFH for IFTF = 1 - the number of interframe time-fill characters as FNUM in the transmit descriptor. For the values FNUM = 0, 1, 2 we have - FNUM = 0 frame 1, 7EH, frame 2 (start flag = end flag) - FNUM = 1 frame 1, 7EH, 7EH, frame 2 - FNUM = 2 frame 1, 7EH, IC, 7EH, frame 2 - the correction of the number of interframe time-fill characters by 1/8 of the number of zero insertions by programming FA in the channel specification. - FA = 0: FNUM from the transmit descriptor is taken directly to determine the number of interframe time-fill characters as shown in Figure 39. - FA = 1: FNUM from the transmit descriptor is reduced by 1/8 of the number of the zero insertions of the frame corresponding to the transmit descriptor as shown in Figure 40. This allows for a more or less constant bit rate transmission for long HDLC frames.
User's Manual
76
01.2000
PEB 20320
Functional Description
7 EH
Frame 1 x Zero Insertions
7 EH . . . . . . 7 EH Frame 2 y+1 x ], 0) 8
y= max (FNUM - [
FE=1
FNUM
Data Contents of Frame 1
Data Contents of Frame 2
ITD04579
Figure 40 Note: 1.
x x -- is the biggest integer smaller than -- . 8 8 x 1. For FNUM - -- < 0, y = 0 8
- the kind of Frame Check Sequence (FCS) two kinds of frame check sequences are implemented by the CRC bit in the channel specification CRC = 0: the generator polynomial x16 + 12 + x5 + 1 is used (2 byte FCS of CCITT Q.921) CRC = 1: the generator polynomial x32 + x26 + x23 + x22 + x16 + x12 + x11 + ... ... x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (4 byte FCS) is used - the suppression of the automatic generation of the FCS is programmable in the channel specification: - CS = 0: FCS generated automatically CS = 1: FCS generation suppressed and in the transmit descriptor CSM = 0: FCS generated automatically if CS = 0 in the channel specification CSM = 1: FCS generation suppressed
User's Manual
77
01.2000
PEB 20320
Functional Description Interrupts The possible interrupts for the mode in transmit direction are: HI: FI: issued if the HI bit is detected in the transmit descriptor (not maskable) issued if the FE bit is detected in the transmit descriptor (maskable by FIT in the channel specification)
ERR: one of the following transmit errors has occurred: - the last descriptor had H = 1 and FE = 0 - the last descriptor had NO = 0 and FE = 0 (maskable by TE in the channel specification) FO: one of the following transmit errors have occurred - a BERR = `0' was detected during a read access to a transmit data section for this channel - the MUNICH32 was unable to access the shared memory in time either for new data to be sent or for a new transmit descriptor. (maskable by TE in the channel specification)
typical data stream has the form ... ITF Example: HDLC channel with CS = 0) (FCS generated automatically) INV = 0 (no inversion) CRC = 0 (CRC16) TRV = 00 (required as unused in HDLC mode) FA = 1 (flag adjustment) MODE = 11 (HDLC) IFTF = 1 (interframe time-fill `1's) INTEL interface Channel number 1A FLAG DATA FCS FLAG ITF ...
User's Manual
78
01.2000
PEB 20320
Functional Description
Generate FI, HI-Int. 2000181A 1st Desc 31 0 A0010002 0 2 nd Desc 31 0 80060801 0
Generate FI-Int. 2000081A 3 rd Desc 31 0 80030800 0
Generate FI-Int. 2000081A
31
0 AA FE=1 HOLD=0 HI=0 NO=6 CSM=1 FNUM=1
31 0 FF FF FF FF 00 FF
31 Address
0 FA 28 AA
FE=1 HOLD=0 HI=1 NO=1 CSM=0 FNUM=2 Time Increases FLAG DATA 1
1
FE=1 Increases HOLD=0 HI=0 NO=3 CSM=1 FNUM=0 Zero Insertion
FCS
2
FLAG
ITF
3
..... 01111110 01010101 00010100010111110 01111110 11111111 8 Zero Insertion FLAG DATA 2
4
FLAG
5
01111110 111110111110111110111110111110111110111110111110 00000000 01111110 Zero Insertion DATA 3 FLAG
ITD04578
0101010100010100010111110 01111110
Figure 41 Note: 1. Data is transmitted according to 2.8 of CCITT recommendation Q.921 2. Note: FCS in the data section is formatted as ordinary data!!! 3. FCS is generated here automatically as CS = 0 and CSM = 0 for the 1st descriptor. 4. There was 1 zero insertion in the 1st frame, so FNUM - -- = FNUM = 2. 8 Therefore between the first and the second frame we have FLAG ITF FLAG and ITF = FFH because IFTF = 1.
User's Manual 79 01.2000 1
PEB 20320
Functional Description 5. No FCS is generated here as CSM is `1' for the second and third transmit descriptor. The FCS is supposed to be the last 2 bytes to be transmitted in this case, their validity is not checked internally. 6. There was 8 zero insertions in the 2nd frame, so FNUM - Therefore between the second and the third frame we have a shared FLAG.
8 -8
= FNUM - 1 = 0.
For CS = 1 (CRC select) the transmitted data stream would differ at FCS, FCS would just be omitted. For INV = 1 (channel inversion) all bits of the data stream (including FLAG, DATA, FCS, ITF) would be inverted. For CRC = 1 (CRC 32) the transmitted data stream would only differ in the FCS, the FCS would be 1101 0111 1010 0101 1000 0000 0010 0111. For FA = 0 (no flag adjustment) the transmitted data stream would change only after DATA 2. The value FNUM = 1 in the second descriptor would alone determine the number of interframe time-fill characters, the scenario would look like DATA 2 FLAG 0111 111 DATA 3
FLAG 0111 111
Figure 42 For IFTF = 0 (ITF flags) the transmitted data stream would only differ at ITF, the 8 ones would be replaced by 0111 1110. For Motorola interface the only difference is in the data section For the first descriptor it ought to be 31 AA and for the second 31 FF 00 and for the third 31 AA 28 FA
80 01.2000
0
0
FF FF FF FF
0
User's Manual
PEB 20320
Functional Description HDLC Receive Direction General Features In receive direction: 1. The starting and ending flag (7EH before and after a frame) is recognized and extracted. 2. A change of the interframe time-fill is recognized and reported by an interrupt. 3. The zero insertions (a `0'-bit after five `1's within a frame) are extracted. 4. The FCS at the end of a frame is checked, it is (optionally) transferred to the shared memory together with the data. 5. The number of the bits within a frame (without zero insertions) is checked to be divisible by 8. 6. The number of bytes within a frame is checked to be smaller than MFL + 1 (after extraction of `0' insertions). 7. The number of bits within a frame after extraction of `0' insertions is checked to be greater than (case NSF = 0 only) (case NSF = 0 only) (only for CS = 0) check a) check b) 16 for CRC = 0 32 for CRC = 1 32 for CRC = 0 48 for CRC = 1 (case NSF = 1 & CS = 1 only) check a') 8 for CRC = x (ignored) 8. The occurrence of an abort flag (7FH) ending a frame is checked. More detailed description of the individual features: 1. a. A frame is supposed to have started if after a sequence of 0111 1110 in the receive data stream neither FCH nor FDH nor 7EH has occurred. The frame is supposed to have started with the first bit after the closing `0' of the sequence. b. A frame is supposed to have stopped if a sequence of 0111 1110 or 0111 1111 is found in the data stream after the frame has started. The last bit of the frame is supposed to be the bit preceding the `0' in the above sequences. The cases of sequences 0111 1110 1111 111 and 0111 1110 0111 1111 are also supposed to be frames of bit length - 1 and 0 respectively. A frame is also supposed to have stopped if more than MFL bytes were received since the start of the frame and it wasn't stopped yet. c. The ending flag of a frame may be the starting flag of the next frame (shared flags supported).
User's Manual
81
01.2000
PEB 20320
Functional Description 2. The receiver is always in one of two possible interframe time-fill states: to be called F and O. The following diagram explains them. A change from F to O and from O to F is reported by an IFC interrupt.
RESET or Receive OFF Receive Initialize Channel Command O 011111101111110 or 0111111001111110 in the Data Stream (2 contiguous Flags received, Flags with shared Zeros supported) 111111111111111 in the Data Stream (15 contiguous "1"s received) or a Receive Abort Channel Command during 15 received Bits
ITD04577
F
Figure 43 3. The `0' extraction is also carried out for the last 6 bits before the stopping sequence. 4. The last 16 (CRC = 0) or 32 (CRC = 1) bits of a frame (after extraction of the zero insertions are supposed to be the FCS of the remaining bits of the frame. (For the case of a frame with less than or equal to 16 or 32 bits respectively see discussion of 7). The FCS is always checked, the check is reported in the CRCO bit of the last receive descriptor of the frame CRCO = 1: FCS was incorrect CRCO = 0: FCS was correct. 5. The check is reported in the NOB bit in the last receive descriptor of the frame NOB = 1: The bit length of the frame was not divisible by 8. NOB = 0: The bit length of the frame was divisible by 8. If NOB = 1: The last access to a receive data section of the frame may contain erroneous bits and shouldn't be evaluated. 6. The check is reported in the LFD bit in the last receive descriptor of the frame. LFD = 1: The number of bytes was greater than MFL. LFD = 0: The number of bytes was smaller or equal to MFL. Only the bytes up to the MFL + 1st one for CS =1 MFL - 1st one for CS = 0, CRC = 0 MFL - 3rd one for CS = 0, CRC = 1 are transferred to be stored memory. The bytes of the last access may be erroneous and shouldn't be evaluated.
User's Manual 82 01.2000
PEB 20320
Functional Description 7. For frames not fulfilling check a) no data are transferred to the shared memory irrespective of CS. Only an interrupt with the bit FI, SF and (possibly) ERR is generated. For frames fulfilling check a) but not check b) data is transferred to the shared memory but the SF bit in the last receive descriptor is set. 8. The check is reported in the RA bit in the last receive descriptor of the frame RA = 1: The frame was stopped by the sequence 7FH RA = 0: The frame was not stopped by the sequence 7FH. Note: A receive descriptor with RA = 1 may also result from a fast receive abort or a receive abort channel command or from a receive descriptor with set HOLD bit. Options The different options for this mode are: - The kind of Frame Check Sequence (FCS) Two kinds of FCS are implemented and can be chosen by CRC bit. CRC = 0: the generator polynomial x16 + x12 + x5 + 1 is used (2 byte FCS of CCITT Q.921) CRC = 1: the generator polynomial x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (4 byte FCS) is used. - the transfer of the FCS together with the received data is programmable by the CS bit. CS = 0: FCS is not transferred to the data section CS = 1: FCS is transferred to the data section. Note: FCS is always checked irrespective of the CS bit. Interrupts The possible interrupts for the mode in receive direction are: HI: FI: issued if the HI bit is detected in the receive descriptor (not maskable) issued if a received frame has been finished as discussed in 1.b of the protocol features (also for frames which do not lead to data transfer as discussed in 7. of the protocol features) (maskable by FIR in the channel spec.)
IFC: issued if a change of the interframe time-fill state as discussed in 2. has occurred. (maskable by IFC in the channel spec.) SF: a frame not fulfilling check a) has been detected (maskable by SFE in the channel spec.)
User's Manual
83
01.2000
PEB 20320
Functional Description ERR: issued if one of the following error conditions has occurred: - FCS was incorrect - the bit length was greater than MFL - the frame was stopped by 7FH - the frame could only be partly stored because of internal buffer overflow of RB - a fast receive abort channel command was issued - a receive abort channel command was detected during reception of a frame - a frame could only be partly transferred to the shared memory because of a receive descriptor with HOLD bit set (maskable by RE in the channel spec.) FO: issued if due to inaccessibility of internal buffer RB - one ore more complete frames have been lost - one ore more changes of interframe time-fill state were lost (maskable by RE in the channel spec.)
Example: HDLC channel with CS = 1 (FCS transferred to shared memory) INV = 0 (no inversion) CRC = 1 (CRC 32) TRV = 00 (required as unused in HDLC mode) FA = x (irrelevant) MODE = 11 (HDLC) IFTF = x (irrelevant) Motorola interface Channel No. 1D MFL = 10
User's Manual
84
01.2000
PEB 20320
Functional Description
FLAG .....
1
DATA 1, FCS 1
01111110 0100 0011 1000 0101 1000 0000 1100 0000 1001 1100 0000 0001 10111100
2 DATA Ignored up to next Flag 0011 1101 0011 11100 0011 1000 0110 0011 1101 1011 0010 0100 3
Abort Sequence 01111111
Generate HI-Int. 8800203D 1st Desc 31 0 20080000 40080000 2 nd Desc 31 0 000C0000 C0031C00
Generate FI, ERR-Int. 8800123D
DATA 2
4
31 0 C2 A1 01 03 39 80 3D BC
31 CRCO, NOB, LFD 5
0
Last Access of a LFD Frame should be Ignored
ITD04576
Figure 44
User's Manual
85
01.2000
PEB 20320
Functional Description
Zero Insertion FLAG 01111110 DATA 2 0000 0000 0011 0101 1001 0010 1101 1111 0 Zero Insertion FCS 2
0000 0011 0010 0101 0100 1111 0101 1111 0 Zero Insertion (shared) FLAG 6 DATA 3 01111110 0000 0000 0011 0101 1001 0010 1101 1111 0 Zero Insertion Missing FCS 3 0000 0011 0010 0101 0100 1111 0101 1111 FLAG 01111110 Generate FI, HI-Int. 8800303D 3 rd Desc 31 0 200C0000 C0080000 4 th Desc 31 0 000C0000 C0081800 Generate FI, ERR-Int. 8800123D
DATA 2 FCS 2
31 0 00 AC 49 FB C0 A4 F2 FA
CRCO, NOB
31 0 00 AC 49 FB DATA 3
ITD04575
Last Access of a NOB Frame should be Ignored
Figure 45
User's Manual 86 01.2000
PEB 20320
Functional Description
DATA 4
FCS 4
0101 0101 1101 1110 1010 0101 1000 0000 0010 0111 2 Flags with shared 0 FCS 5 0111 1110 111 1110 FLAG 01111110 DATA 6 0000 0000 0000 0000 0000 0000 0000 0000 FCS 6
FLAG 01111110 Abort Sequence 01111111
0101 0101 1101 1110 1010 0101 1000 0000 0010 0111
7
DATA Ignored up to next Flag
15 x "1"
12
1 1111110101000110011100111010 0111 1111 1111 1111 01110 011111100011111101111111 Generate FI-Int. 8800103D Generate IFC-Int. (2 Flags) 8800083D Generate short Frame Interrupt for FCS 5 8800143D 5 th Desc 31 0 000C0000 C0050000
9
10
5
Generate FI, ERR-Int. 8800123D Generate IFC-Int. 11 (15 * 1) 8800083D Generate Short Frame Interrupts 8800163D 8800163D
6 th Desc 31 0 00140000 C0050200
DATA 4 FCS 4
8
31 0 AA 7B A5 01 E4 XX XX XX
RA
31 0 AA 7B A5 01 E4 XX XX XX
ITD04574
Figure 46 Note: 1. After Receive Initialization is detected all data are ignored until a flag is received. The receiver is in the interframe time-fill state `0'. 2. After MFL + 1 data bytes are received the further data are ignored (except for a change of the interframe time-fill state) and are neither stored in the RB nor reported to the shared memory. The receiver waits for the next flag. 3. Even the abort sequence at the end of the frame will not lead to the RA bit in the descriptor to be set. 4. Data are formatted according to 2.8 of CCITT Q.921. 5. The FCS is formatted as ordinary data!!!
User's Manual 87 01.2000
PEB 20320
Functional Description 6. LFD is issued and always accompanied by NOB. CRCO shouldn't be interpreted for a LFD frame. 7. Here the ending flag of the second frame is the starting flag of the third frame. 8. After an abort sequence data is ignored until a flag is found (except for a change of the interframe time-fill state). They are neither stored in the RB nor reported to the shared memory. 9. The last 3 bytes in the last write access to the receive data section of the 5th descriptor have to be ignored. 10.The 2 flags with a shared 0 in the middle change the original interframe timefill state `0' of the receiver to `F'. The 2 flags following FCS 5 on the other hand do not change the interframe time-fill state, as it already was `F'. 11.The frame consisting only of 32 times 0 between 2 flags does not pass check a). It only leads to an interrupt. 12.The 15 x `1' leads to a change of the interframe time-fill state from `F' to `0' even through it is in a data ignored zone. 13.This frame of length - 1 leads to an interrupt. For CS = 0 (CRC not select) the descriptor would have looked like
Generate HI, FI, ERR-Int. 8800323D 1st Desc 1 31 0 20080000 C0071C00 3 rd Desc 2 31 0 200C0000 C0040000
Generate HI, FI-Int. 8800303D
31 0 C2 A1 01 03
31 0 00 AC 49 FB
ITD04572
Last Access of a LFD Frame should be Ignored
Figure 47
User's Manual 88 01.2000
PEB 20320
Functional Description
Generate FI, ERR-Int. 8800123D 4 th Desc 31 0 000C0000 C0041800 5 th Desc 31 0 000C0000 C0014000
Interrupts as in the original Example 6 th Desc 31 0 00140000 C0014200
31 CRCO, NOB
0 SF
31 0 AA XX XX XX
SF, RA
31 0 AA XX XX XX
ITD04573
Last Access of a NOB Frame should be Ignored
Figure 48 Note: 1. Only the 7 leading bytes are reported (the last 4 are supposed to be the FCS even in this case). 2. It is assumed here for convenience that the first descriptor points to the third and not to the second descriptor as in the original example. For INV = 1 (channel inversion) all bits of the data stream (including DATA, FCS, flag, abort sequence 15 x `1') are interpreted inversely. e.g. `1000 0001' would be interpreted as flag 15 x `0' would lead to a change from interframe time-fill state `F' to `0' etc.
User's Manual
89
01.2000
PEB 20320
Functional Description For CRC = 0 (CRC 16) the correct FCS e.g. zeros for DATA 4 would be 00001 0100 0101 1110 the 5th descriptor would then be
5 th Desc 31 0 000C0000
C0034000 31 0 AA 28 FA XX
ITD04570
Figure 49 For Intel interface the only difference is in the receive data sections. They would be
of 1st Desc 31 0 03 01 A1 C2 BC 30 80 39
of 3 rd Desc 31 0 FB 49 AC 00 FA F2 A4 C0
of 5 th Desc 31 0 01 A5 7B AA XX XX XX E4
ITD04571
Figure 50
User's Manual
90
01.2000
PEB 20320
Functional Description TMB Transmit Direction General Features In transmit direction: - The starting and ending flag (00H before and after a frame) - The interframe time-fill between frames is generated automatically. Options The different options for this mode are: - The number of interframe time-fill characters as shown in Figure 26 by choosing FNUM in the transmit descriptor. For the values FNUM = 0, 1, 2 we have FNUM = 0 FNUM = 1 FNUM = 2 Interrupts The possible interrupts for the mode in transmit direction are identical to those of HDLC. A typical data stream has the form ITF DATA ITF DATA Example TMB channel with INV = 0 (no inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required) MODE = 01 (TMB) IFTF = 0 (required) Intel interface Channel number 5 ... frame 1, 00H, frame 2 ... (start = end flag) ... frame 1, 00H, 00H, frame 2 ... ... frame 1, 00H, 00H, 00H, frame 2 ...
User's Manual
91
01.2000
PEB 20320
Functional Description
Generate HI-Interrupt 88002005
2
Generate FI-Interrupt 88001005
3
Generate FI-Interrupt 88001005
31 20020000
0
31 80000000
0
31
0
80030001 0
0
31
0 CE AB
31
0 45 23 01
1
FLAG ..... 0 0
DATA 1 FLAG
DATA 2
2 FLAGS
ITD04569
D 5 7 3 0 0 8 0 C 4 A 2 0 0 0 0 .....
Figure 51 Note: 1. Data is transmitted according to Q.921 2.8 and fully transparent. 2. A transmit descriptor with NO = 0 and FE = 1 is allowed, one with NO = 0 and FE = 0 is forbidden. 3. FNUM = 1 leads to 2 FLAGS after DATA 2.
User's Manual
92
01.2000
PEB 20320
Functional Description TMB Receive Direction General Features 1. The starting and ending flag (00H before and after a frame) as well as interframe timefill is recognized and extracted. 2. The number of bits within a frame is checked to be divisible by 8. 3. The number of bytes within a frame is checked to be smaller than MFL + 1. 4. A frame containing less than 8 bits may be ignored completely by the receiver. More detailed description of the individual features: 1. a. A frame is supposed to have started if after a sequence `0000 0000' a `1'-bit is recognized. The frame is supposed to have this `1'-bit as first bit. b. A frame is supposed to have stopped if - either a sequence 0000 0000 1 is found in the data stream after the frame has started - or a sequence 0000 0000 is found octet synchronous (i.e. the first bit of the sequence 00H is the 8 m + 1st bit since the starting `1'-bit of 1.a. for an integer m). In both cases the last bit before the sequence 00H is supposed to be the last bit of the frame. 2. The check is reported in the NOB bit in the last receive descriptor of the frame. NOB = 1: The bit length of the frame was not divisible by 8. NOB = 0: The bit length of the frame was divisible by 8. 3. The check is reported in the LFD bit in the last receive descriptor of the frame. LFD = 1: The number of bytes was greater than MFL. LFD = 0: The number of bytes was smaller or equal to MFL. Only the bytes up to the MFl + 1st one are transferred to the shared memory. The bytes of the last access to the receive data section of the frame may contain erroneous bits and shouldn't be evaluated. LFD is always accompanied by NOB. Options There are no options in receive direction for this mode.
User's Manual
93
01.2000
PEB 20320
Functional Description Interrupts The possible interrupts for the mode in receive direction are: HI: FI: issued if HI bit is detected in the receive descriptor (not maskable). issued if a received frame has been finished as discussed in 1b) of the protocol features or a receive abort channel command was detected during reception of a frame. (maskable by FIR in the channel spec.)
ERR: issued if one of the following error conditions has occurred - the bit length of the frame was not divisible by 8 - the byte length was greater than MFL - the frame could only be partly stored because of internal buffer overflow of RB - a fast receive abort channel command was issued - the frame could only be partly transferred due to a receive descriptor with set HOLD bit. (maskable by RE in the channel specification) FO: issued if due to inaccessibility of the internal buffer RB one or more complete frames have been lost. (maskable by RE in the channel spec.)
Example: TMB channel with INV = 0 (no inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required) MODE = 01 (TMB) IFTF = 0 (required) MFL = 7 Motorola interface Channel No. A
User's Manual
94
01.2000
PEB 20320
Functional Description
FLAG 00000000
1
DATA 1 10111001 10000000
octet synchronous FLAG 00000000
3
DATA 2 11001011
octet synchronous FLAG 00000000
DATA 3 10000000
00
(start) FLAG non octet synchronous FLAG 10111100 0000000
4
DATA 4 10000000 11111110 01111111 11111011 11010101 01001100
5 DATA Ignored up to next Framestart
FLAG 10100000 11110111 01010101
DATA 5 00101010
FLAG 0000 0000
0000 0000 0000 10101101
Generate FI-Int. 8800102A 1 st Desc 31 0 00040000 C0020000 2 nd Desc 31 0 200C0000 C0010000
Generate FI, 8800302A
HI-Int.
Generate FI, 8800322A
HI, ERR-Int.
3 rd Desc 31 0 20080000 C0020800
DATA 1
2
31 0 9D 01 XX XX
31 0 DATA 2 D3 XX XX XX
31 NOB DATA 3
0
ITD04568
Last Access of a NOB Frame should be Ignored
Figure 52
User's Manual 95 01.2000
PEB 20320
Functional Description
Generate HI-Int. 8800202A 4 th Desc 31 0 20080000 40080000 5 th Desc 6 31 0 00040000 C0000C00
Generate FI, 8800122A
ERR-Int.
Generate FI-Int. 8800102A
6 th Desc 31 0 00FC0000 C0020000
DATA 4
31 0 01 7F FE DF
LFD, NOB
DATA 5
31 0 B5 54 XX XX
ITD04567
Last Access of a LFD Frame should be Ignored
Figure 53 Note: 1. After Receive Initialization is detected all data are ignored until the starting sequence 0000 0000 1 is detected. 2. Data are formatted according to 2.8 of CCITT Q.921. 3. The octet synchronous (end) flag of one frame can be part of the (start) flag of the next frame. Between DATA 1 and DATA 3 they are identical (shared flags supported). 4. Here the sequence 0000 0000 1 is detected non-octet synchronously. Therefore the frame belonging to DATA 3 is supposed to have ended non-octet synchronously (NOB set in the 3rd descriptor). 5. After MFL + 1 data bytes the further data are ignored and are neither stored in the RB nor reported to the shared memory. The receiver waits for the next sequence 0000 0000 1 to come. 6. If a receive descriptor is full (4th desc.) the MUNICH32 branches to the next receive descriptor (5th desc.) even if no further data are to be given to the shared memory.
User's Manual
96
01.2000
PEB 20320
Functional Description For INV = 1 (channel inversion) all bits of the data stream (including DATA, FLAG) are interpreted inversely e.g. 1111 1111 0 would be interpreted as starting sequence then. For Intel interface the only difference is in the receive data sections. They would be
of 1st Desc 31 0 XX XX 01 9D
of 2 nd Desc 31 0 XX XX XX D3
of 4 th Desc 31 0 DF FE 7F 01
of 6 th Desc 31 0 XX XX 54 B5
ITD05034
Figure 54
User's Manual
97
01.2000
PEB 20320
Functional Description TMR Transmit Direction General Features In transmit direction - the starting and ending flag (00 00H or 0 00H between frames) is generated automatically. Options The different options for this mode are - the number of interframe time-fill characters as shown in Figure 29 by choosing FNUM in the transmit descriptor. For the values 0, 1, 2 we have FNUM = 0 FNUM = 1 FNUM = 2 ... frame 1, 000H, frame 2 ... ... frame 1, 00H, 00H, frame 2 ... ... frame 1, 00H, 00H, 00H, frame 2 ...
By choosing FNUM = 0 and setting the last transmitted nibble in the transmit data section to 0H frames of effective length n + 1/2 bytes can be sent as required by GSM 08.60. Interrupts The possible interrupts for the mode in the transmit direction are identical to those of HDLC. A typical data stream has the form ITF DATA ITF DATA Example: TMR channel with INV = 0 (no inversion) CRC = 1 (required) TRV = 00 (required) FA = 0 (required) MODE = 01 (TMR) IFTF = 0 (required) Intel interface Channel No. 5
User's Manual
98
01.2000
PEB 20320
Functional Description
Generate HI-Interrupt 88002005
2
Generate FI-Interrupt 88001005
3
Generate FI-Interrupt 88001005
31 20020000
0
31 80000000
0
31
0
80030001 0
0
31
0 0E AB
31
0 45 23 01
1
FLAG ..... 0 0
DATA 1
FLAG
DATA 2
2 FLAGS
ITD04566
D 5 7 0 0 0 8 0 C 4 A 2 0 0 0 0 .....
Frame of Effective Length 1 1/2 Byte
Figure 55 Note: 1. Data is transmitted according to Q.921 2.8 and fully transparent. 2. A transmit descriptor with NO = 0 and FE = 1 is allowed, one with NO = 0 and FE = 0 is forbidden. 3. FNUM = 1 leads to 2 FLAGS after DATA 2.
User's Manual
99
01.2000
PEB 20320
Functional Description TMR Receive Direction General Features 1. The starting and the ending flag (00 00H) is recognized. Interframe time-fill, both characters of the starting flag and the last character of the ending flag is extracted. 2. The number of bits within a frame is checked to be divisible by 8. 3. The number of bytes within a frame is checked to be smaller than MFL. More detailed description of the individual features 1. a. A frame is supposed to have started after a sequence of 16 zeros a `1'-bit is recognized. The frame is supposed to have this `1'-bit as first bit. b. A frame is supposed to have stopped if - either a sequence of 16 `zeros' and a `one' is found in the data stream after the frame has started - or a sequence of 16 zeros is found octet synchronous (i.e. the first bit of the sequence 00 00H is the 8m + 1st bit since the starting `1'-bit of 1.a. for an integer m). In both cases the eighth bit of the sequence 00 00H is supposed to be the last bit of the frame. 2. The check is reported in the NOB bit in the last receive descriptor of the frame. NOB = 1 the bit length of the frame was not divisible by 8. NOB = 0 the bit length of the frame was divisible by 8. If NOB = 1 the last byte of the last access to a receive data section of the frame may contain erroneous bits and shouldn't be evaluated. This does not affect the reception of frames with n + 1/2 octets 3. The check is reported in the LFD bit in the last receive descriptor of the frame. LFD = 1 the number of bytes was greater than MFL. LFD = 0 the number of bytes was smaller or equal to MFL. MFL + 1st one are transferred to the shared memory. The bytes of the last access to the receive data section of the frame may contain erroneous bits and shouldn't be evaluated. LFD is always accompanied by NOB.
User's Manual
100
01.2000
PEB 20320
Functional Description Options There are no options in receive direction for this mode. Interrupts The possible interrupts for the mode in receive direction are identical to those of TMB. Example: TMR channel with INV = 0 (no inversion) CRC = 1 (required) TRV = 00 FA = 0 MODE = 01 (TMR) IFTF = 0 (required) MFL = 7 Motorola interface Channel No. 15
User's Manual
101
01.2000
PEB 20320
Functional Description
(start) FLAG .... 00000000
1
DATA 1 10111001 10000000
octet synchronous (end) FLAG 2 00000000 00000000 (start) FLAG 0000
DATA 2 11001011
octet synchronous FLAG 00000000
00000000
00000000
DATA 3 10000000 00000000 10111100 11110101
non octet synchronous FLAG 11000000 00000000
3
0000 11110001 11011111 01011001 01101010 octet synchronous (end) FLAG 00000000 00000000
DATA 4 11110011 11110111 11011101 11011011
4 DATA Ignored up to next Framestart
DATA 5 00000000 11011101 01111010
11111111
00000000
Generate FI-Int. 88001035 1 st Desc 31 0 00040000 C0030000 2 nd Desc 31 0 200C0000 C0020000
Generate FI, HI-Int. 88003035 3 rd Desc 31 0 00080000 C0060800
Generate FI, ERR-Int. 88001235
DATA 1
5
31 0 9D 01 00 XX
31 0 DATA 2 D3 00 XX XX
NOB
31 0 01 00 3D AF 03 XX XX XX Last Byte of a NOB Frame should be Ignored
DATA 3 Generate FI, HI, ERR-Int. 88003235 6 th Desc 31 0 00080000 C0030000
Generate HI-Int. 88002035 4 th Desc 31 0 20080000 40080000 5 th Desc 6 31 0 20040000 C0000C00
Generate FI-Int. 88001035
31 0 DATA 4 8F FB 9A 56
LFD, NOB
31 0 DATA 5 BB 5E 00 XX
Last Access of a LFD Frame should be Ignored
ITD04565
Figure 56
User's Manual 102 01.2000
PEB 20320
Functional Description 1. After receive initialization is detected all data are ignored until a starting sequence (16 `zeros', `one') is detected. 2. The octet synchronous (end) flag of one frame can be part of the (start) flag of the next frame. Note, that the first 00H character of the end flag is stored in the receive data section as ordinary data and is included in BNO. Between DATA 2 and DATA 3 the start and end flag are identical (shared flags supported). 3. Here the start sequence is detected non-octet synchronously within a frame. Therefore the frame belonging to DATA 3 is supposed to have ended non-octet synchronously (NOB set in the 3rd descriptor). 4. After MFL + 1 data bytes the further data are ignored and are neither stored in the RB nor reported to the shared memory. 5. Data are formatted according to 2.8 of CCITT Q.921. 6. If a receive descriptor is full (4th descriptor) the MUNICH32 branches to the next receive descriptor (5th descriptor) even if no further data are to be given to the shared memory. For INV = 1 (channel inversion) all bits of the data stream (including DATA, FLAG) are interpreted inversely e.g. 16 `ones', `zero' is interpreted as starting sequence then. For Intel interface the only difference is in the receive data sections. They would be
of 1st Desc 31 0 XX 00 01 9D
of 2nd Desc 31 0 XX XX 00 D3
of 3rd Desc 31 0 AF 3D 00 01 XX XX XX 03
of 4th Desc 31 0 56 9A FB 8F
of 6 th Desc 31 0 XX 00 5E BB
ITD05035
Figure 57
User's Manual
103
01.2000
PEB 20320
Functional Description TMA Transmit Direction General Features In the transmit direction - a slot-synchronous transparent data transmission - a high impedance overwrite for the masked bits in the slot - a programmable number of programmable fill characters between data (also slot synchronous) is generated automatically. Options The different options for this mode are - The value of the fill-character can be programmed for FA = 1 in the channel specification. The fill-character (TC) is then programmed in the TFLAG. For FA = 0 the fill character is FFH and TFLAG has to be set to 00H. If subchanneling is chosen (not all fill/mask bits of the channel are `1') FA must be set to `0'. - The number of inter-data time-fill characters as shown in Figure 33 by choosing FNUM = 0, 1, 2 we have FNUM = 0 FNUM = 1 FNUM = 2 Interrupts The possible interrupts for this mode in transmit direction are identical to those of HDLC. ... DATA 1, TC, DATA 2 ... ... DATA 1, TC, TC, DATA 2 ... ... DATA 1, TC, TC, TC, DATA 2 ...
User's Manual
104
01.2000
PEB 20320
Functional Description Example 1: (no subchanneling by fill/mask bits) TMA channel with TFLAG = B2H INV = 0 (no data inversion) CRC = 0 (required) TRV = 00 (required) FA = 1 (flag filtering) MODE = 00 (TMA) IFTF = 0 (required) All fill-mask bits are `1' for this channel (no high impedance overwrite) Intel interface Channel no. D
Time-Slot Boundaries Bit No
0 70 70 70 70 70 70 70 70 70 70 70 70 DATA 1 .....
1
DATA 2
TC
2
DATA 3 2 TCs
DATA 4
D 5 8 B 6 C 4 8 0 0 B 2 4 F B 2 B 2 8 B B 4 4 C .....
Generate HI-Interrupt 8800200D 1 st Desc 31 0 20020000 0 2 nd Desc 31 0 A0030000 0
Generate HI-, FI-Interrupt 8800300D 3 rd Desc 31 0 80010001 0 4 th Desc 31 0 00030000 0
31 0 DATA 1 XX XX D1 AB
31 0 DATA 2 XX 00 12 36
31 0 DATA 3 XX XX XX F2
31 0 DATA 4 XX 32 2D D1
ITD04564
For INV=1 DATA and TC would be Inverted
Figure 58 Note: 1. Data are formatted according to 2.8 of Q.921. The TC is transmitted MSB (bit 15) first though!!! 2. FNUM = 0 in the second descriptor leads to the insertion of the TC after DATA 2, FNUM = 1 in the third descriptor to the insertion of 2 TCs.
User's Manual 105 01.2000
PEB 20320
Functional Description For INV = 1 the data stream would be inverted completely
DATA 1 DATA 2 ... 2A 74
TC DATA 3 2 TCs B0
DATA 4
93 B7 FF 4D
4D 4D 74 4B B3 ...
Figure 59 For FA = 0 TFLAG has to be programmed to 00H and the data stream would be
DATA 1 DATA 2
TC DATA 3 2 TCs 4F
DATA 4
D5 8B 6C 48 00 FF
FF FF 8B B4 4C
Figure 60 For Motorola mode the data sections leading to the same data stream would have been
of 1st Desc 31 0 AB D1 XX XX
of 2nd Desc 31 0 36 12 00 XX
of 3 rd Desc 31 0 F2 XX XX XX
of 4 th Desc 31 0 D1 2D 32 XX
ITD05036
Figure 61
User's Manual
106
01.2000
PEB 20320
Functional Description Example 2: (subchanneling by fill/mask bits) TMA channel with TFLAG = 00H (required for this case) INV = 0 (no data inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required for subchanneling) MODE = 00 (TMA) IFTF = 0 (required) Intel interface Channel no. D
Generate HI-Interrupt 8800200D 1 st Desc 31 0 20020000 0 2 nd Desc 31 0 A0030000 0
Generate HI-Interrupt 8800200D 3 rd Desc 31 0 80010001 0 4 th Desc 31 0 00030000 0
31 0 DATA 1 XX XX D1 AB
31 0 DATA 2 XX 00 12 36
31 0 DATA 3 XX XX XX F2
31 0 DATA 4 XX 32 2D D1
ITD04563
Figure 62
User's Manual
107
01.2000
Figure 63
User's Manual
012345670123456701234567012345670123456701234567 110101011000101101101100010010000000000011111111 Z1ZZ01Z110001011ZZZZZZZZ01Z010Z0000Z0Z00ZZ111111 DATA 1 (D5 8B) DATA 2 (6C 48 00) TC (FF)
ITD04561
Slot Boundaries
Bit No
010011011111111100000000110111011110101100111111 Fill/Mask High Imp. Overwrite
Internal Data
External Data (TDATA)
Note: Example 2 uses the same descriptors as example 1. Those bits in the data stream that are at places where fill/mask is `zero' are overwritten by `Z' i.e. high impedance. In all other protocols bits of the data stream are not overwritten by fill/mask zero bits. Instead the whole data stream is sent at fill/mask one bits for all other protocols.
012345670123456701234567012345670123456701234567 010011111111111111111111100010111011010001001100 010Z11111Z11111Z111Z1111Z0001Z11ZZ110Z00Z1001100 DATA 3 (4F) 2 TCs (FF FF) DATA 4 (8B B4 4C)
ITD04562
108
Slot Boundaries
Bit No
111011111011111011101111011110110011101101111111 Fill/Mask High Imp. Overwrite
Internal Data
External Data
PEB 20320
Functional Description
01.2000
PEB 20320
Functional Description TMA Receive Direction General Features In the receive direction - a slot synchronous transparent data reception - a `1' overwrite for masked bits in the slot - for FA = `1' a slot synchronous programmable flag extraction is performed automatically. Options The different options for this mode are: - the programmable character TC to be extracted for FA = `1' is TFLAG. For FA = `0' nothing is extracted. If subchanneling is chosen (not all fill/mask bits of the channel are `1') FA must be set to `0'. Interrupts The possible interrupts for the mode in receive direction are: HI: issued if the HI bit is detected in the receive descriptor (not maskable). ERR: issued if a fast receive abort channel command was issued. (maskable by RE in the channel spec.) FO: issued if data could only partially stored due to internal buffer overflow of RB. (maskable by RE in the channel spec.)
Example 1: (no subchanneling) TMA channel with TFLAG = D7 INV = 0 (no channel inversion) CRC = 0 (required) TRV = 00 (required) FA = 1 MODE = 00 (TMA) IFTF = 0 Motorola interface Channel No. E
User's Manual
109
01.2000
PEB 20320
Functional Description
Slot Boundaries
0 70 70 70 70 70 70 70 70 70 70 D6 D7 AF BD 0 0 D7 D7 2 8 6 3 D7 7 D 7 8 Octet Synchr. TC 2 Octet Synchr. TCs Octet Not Synchr. Octet TC Synchr. TC not Filtered Generate HI-Interrupt 8800202E 31 00040000 40040000 0 31 20040000 40040000 0
31 0 6B F5 BD 00
31 0 14 C6 BE 1E
ITD04560
Figure 64 Note: The FE bit is never set in a receive descriptor. The data are formatted according to 2.8 Q.921. For FA = 0 (and therefore TFLAG = 00H) The descriptor would be
Generate HI-Interrupt 8800202E 31 00040000 40040000 0 31 20040000 40040000 0 31 00040000 40040000 0
31 0 6B EB F5 BD
31 0 00 EB EB 14
31 0 C6 EB BE 1E
ITD04559
Figure 65
User's Manual 110 01.2000
PEB 20320
Functional Description For INV = 1 the receiver filters the inverse of the TFLAG as TC out of the data stream and inverts the data (only the octet synchronous 28H would be filtered). For Intel interface the data sections would be 00 BD F5 6B
for the first descriptor and 1E BE C6 14 for the second. Example 2: (with subchanneling) TMA channel with TFLAG = 00H (required because of subchanneling) INV = 0 (no channel inversion) CRC = 0 (required) TRV = 00 (required) FA = 0 (required because of subchanneling) MODE = 00 (TMA) IFTF = 0 Motorola interface Channel No. E
User's Manual
111
01.2000
PEB 20320
Functional Description
Slot Boundaries Fill/Mask "one" Overwrite External Data (RDATA) Internal Data For INV=1 11111111010011000101100010111101 00000000011001101110100100101001 00000000111101111110111101101011 11111111101110111011011111010110
31
0
00040000 40040000
31 0 00 EF F7 D6
ITD04558
Figure 66
User's Manual
112
01.2000
PEB 20320
Functional Description V.110/X.30 Transmit Direction General Features In transmit direction - the synchronization pattern for V.110/X.30 frame as shown in Table 1. - the framing for the different data rates with programmable E-, S-, X-bits - sending `0' before all frames is performed automatically. Table 1 Synchronization Pattern for V.110/X.30-Frames Octet No. 1 2 3 4 5 6 7 8 9 10 1 0 1 1 1 1 1 1 1 1 1 2 0 3 0 4 0 5 0 6 0 7 0 8 0
The E-, S-, X-bits are fed into the data stream by special transmit descriptor (as shown in Figure 30), they can only change from one 10-octet frame to the next, not within a 10octet frame. The data from the data sections are supposed to come in the form:
31 0
1 1 B6 B5 B4 B3 B2 B1 1 1 B12 B11 B10 B9 B8 B7 1 1 B18 B17 B16 B15 B14 B13 1 1 B24 B23 B22 B21 B20 B19
(for Motorola mode),
31 0 1 1 B24 B23 B22 B21 B20 B19 1 1 B18 B17 B16 B15 B14 B13 1 1 B12 B11 B10 B9 B8 B7 1 1 B6 B5 B4 B3 B2 B1
(for Intel mode). where for 600 bit/s e.g. B1 to B6 belong to the first 10-octet frame, B7 to B12 belong to the second 10-octet frame, etc.
User's Manual
113
01.2000
PEB 20320
Functional Description Options The different options for this mode are: - the framing pattern, as shown in Table 2 to Table 5, is programmed by the bits TRV. Interrupts HI: issued if the HI bit is detected in the transmit descriptor (not maskable) ERR: if one of the following transmit errors has occurred - the last descriptor had FE = 1 (leads to an abort of the transmit data, see Figure 31) - the last descriptor had H = 1 (see Figure 29) - the last descriptor had NO = 0 (maskable by TE in the channel spec.) FO: one of the following transmit errors has occurred - a BERR = `0' was detected during a read access to a transmit data section for this channel - the MUNICH32 was unable to access the shared memory in time either for new data to be sent or for a new descriptor. (maskable by TE in the channel spec.)
User's Manual
114
01.2000
PEB 20320
Functional Description Example X.30/V110 channel with CS = 0 (required) INV = 0 CRC = 0 TRV variable (all values shown in examples) FA = 0 (required) MODE = 10 (V.110/X.30) Intel interface Channel No. 1F
Generate HI-Interrupt 8800201F
Generate HI-Interrupt 880201F
31 00028000
0
31 20030000
0
31 20018000
0
31 00030000
0
0
0
0
0
E, S, X
31 0 1 75 40 00 00
31 0 DATA 1 XX FA D6 C3 E, S, X
31 0 2 8A 80 00 00
31 0 DATA 2 XX D1 E2 C0
ITD05037
Figure 67 Note: The first transmit descriptor must have the V.110-bit set.
User's Manual
115
01.2000
PEB 20320
Functional Description TRV = 00
0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 1 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 1 1 0 0 1 0 0 1 0 0 1 1 1 0 1 0 0 0 0 0 0 0 1 1 1 0 0 1 0 0 0 0 1 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 1 1 0 0 0 0 0 1 0 0 1 1 1 0 0 0 0 0 0 0 0 1 1 1 0 0 1 1 0 0 0 1 1 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 1 1 0 1 0 0 0 1 0 1 0 0 0 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 0 0 1 1 1 1 0 1 1 0 0 0 1 1 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1 0 0 1 1 0 0 1 0 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 0 1 0 0 0 0 0 1 0 0 0 1 1 0 0 1 0 0 0 0 0 0 1 1 1 1 0 1 0 0 0 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 0 1 0 0 0 0 0 1 0 0 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 0 1 0 0 1 0 1 0 1 1 0 1 0 SA X SB 1 E1E2E3E4E5E6E7
D6 = 11 0 1 0 1 1 0 B6B5B4B3B2B1
FA = 11 1 1 1 0 1 0 B6B5B4B3B2B1
Change of E-, S-, X-bits
User's Manual
116
01.2000
PEB 20320
Functional Description TRV = 01
0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 0 0 0 0 1 0 1 0 0 1 1 1 0 0 0 0 0 0 0 1 0 0 1 1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 0 1 1 1 1 0 0 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 0 0 0 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 0 0 1 0 0 0 1 0 0 1 0 0 0 1 1 1 1 0 0 1 0 1 1 1 0 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 1 0 1 0 SA X SB 1 E1E2E3E4E5E6E7
FA (last byte of DATA 1)
11 1 1 1 0 1 0 B6B5B4B3B2B1
C0 (first byte of DATA 2) Change of E-, S-, X-bits E2 = 1 1 1 0 0 0 1 0 B6B5B4B3B2B1
11 0 0 0 0 0 0 B6B5B4B3B2B1
D1 = 1 1 0 1 0 0 0 1 B6B5B4B3B2B1
TRV = 10
0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 1 0 1 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 1 0 1 1 0 1 1 0 0 0 1 0 0 1 1 0 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 0 1 0 1 0 1 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 1 0 0 0 0 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 1 0 1 0 SA X SB 1 E1E2E3E4E5E6E7
Change of E-, S-, X-bits E2 = 1 1 1 0 0 0 1 0 B6B5B4B3B2B1 D1 = 1 1 0 1 0 0 0 1 B6B5B4B3B2B1
User's Manual
117
01.2000
PEB 20320
Functional Description TRV = 11
0 1 1 1 1 1 1 1 1 1 0 1 0 0 0 0 0 1 0 1 1 1 0 1 1 0 0 0 1 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 1 0 1 0 1 0 0 0 1 0 1 1 0 0 0 1 0 1 0 0 1 0 1 Change of E-, S-, X-bits
For INV = 1 (channel inversion) all bits are inverted. For Motorola mode the data sections would have to have the form to yield the same output data.
31 0 E, S, X 1 00 00 40 75
31 0 DATA 1 C3 86 FA XX
31 0 31 0 E, S, X 2 00 00 80 8A DATA 2 C0 E2 D1 XX XX XX 00 03
ITD05038
Figure 68
User's Manual
118
01.2000
PEB 20320
Functional Description V.110/X.30 Receive Direction General Features In receive direction - the starting sequence (00H followed by a `1'-bit) after initialization of loss of synchronism is detected. - the synchronization pattern is monitored, after 3 consecutive erroneous frames a loss of synchronism is detected. - a change of E-, S-, X-bits is monitored and reported by an interrupt. - the data bits are extracted and written into the data section. More detailed description of the individual features: 1. and 2. the receiver can be in one of 2 states:
RESET
Unsynchronous State 8 * "0" bit followed by a "1" bit Synchronous State
ITD05039
3 Consecutive Erroneous Frames (with a Frame Error)
Figure 69 Data extraction and monitoring of a change of E-, S-, X-bits and synchronization pattern is only performed in synchronized state. In the asynchronous state the receiver waits for the synchronization patter. The `1'-bit is then interpreted as bit 1 of octet 2. 3. During the synchronized state a change of E, S, X-bits from one frame to the next and even within a frame (for SA, SB bits) is monitored. Only one interrupt per frame is reported even if SA e.g. changes 3 times within the frame. The E-, S-, X-bits reported in the interrupt are S9 for SB and S8 for SA and the second occurrence of X for X. 4. The bits written into the data section are marked by O in Table 2 to Table 4. As shown, bits repeated in the serial data are only strobed than at their last instance.
User's Manual
119
01.2000
PEB 20320
Functional Description Table 2 Framing for Networks with 600-bit/s Data Rate Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 9 10 1 0 1 1 1 1 1 1 1 1 1 2 0 B1 B1 B2 B3 E1 B4 B4 B5 B6 3 0 B1 B1 B2 B3 E2 B4 B4 B5 B6 4 0 B1 B2 B2 B3 E3 B4 B5 B5 B6 5 0 B1 B2 B2 B3 E4 B4 B5 B5 B6 6 0 B1 B2 B3 B3 E5 B4 B5 B6 B6 7 0 B1 B2 B3 B3 E6 B4 B5 B6 B6 8 0 S1 X S3 S4 E7 S6 X S8 S9
Table 3 Framing for Networks with 1200-bit/s Data Rate Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 9 10 1 0 1 1 1 1 1 1 1 1 1 2 0 B1 B2 B4 B5 E1 B7 B8 B10 B11 3 0 B1 B2 B4 B5 E2 B7 B8 B10 B11 4 0 B1 B3 B4 B6 E3 B7 B9 B10 B12 5 0 B1 B3 B4 B6 E4 B7 B9 B10 B12 6 0 B2 B3 B5 B6 E5 B8 B9 B11 B12 7 0 B2 B3 B5 B6 E6 B8 B9 B11 B12 8 0 S1 X S3 S4 E7 S6 X S8 S9
User's Manual
120
01.2000
PEB 20320
Functional Description Table 4 Framing for Networks with 2400-bit/s Data Rate Intermediate Rate = 8 Kbit/s, i.e. Subchannelling with Only 1 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 9 10 1 0 1 1 1 1 1 1 1 1 1 2 0 B1 B4 B7 B10 E1 B13 B16 B19 B22 3 0 B1 B4 B7 B10 E2 B13 B16 B19 B22 4 0 B2 B5 B8 B11 E3 B14 B17 B20 B23 5 0 B2 B5 B8 B11 E4 B14 B17 B20 B23 6 0 B3 B6 B9 B12 E5 B15 B18 B21 B24 7 0 B3 B6 B9 B12 E6 B15 B18 B21 B24 8 0 S1 X S3 S4 E7 S6 X S8 S9
Table 5 Framing for Networks with 4800-, 9600-, 19200-, 38400-bit/s Data Rate Intermediate Rate = 8, 16, 32, 64 Kbit/s, i.e. Subchannelling with 1, 2, 4, 8 Fill/Mask Bit Set Octet No. 1 2 3 4 5 6 7 8 9 10 1 0 1 1 1 1 1 1 1 1 1 2 0 B1 B7 B13 B19 E1 B25 B31 B37 B43 3 0 B2 B8 B14 B20 E2 B25 B32 B36 B44 4 0 B3 B9 B15 B21 E3 B27 B33 B39 B45 5 0 B4 B10 B16 B22 E4 B29 B35 B41 B47 6 0 B5 B11 B17 B23 E5 B29 B35 B41 B47 7 0 B6 B12 B18 B24 E6 B30 B36 B42 B48 8 0 S1 X S3 S4 E7 S6 X S8 S9
They are grouped together in the form:
31 0 1 1 B6 B5 B4 B3 B2 B1 1 1 B12 B11 B10 B9 B8 B7 1 1 B18 B17 B16 B15 B14 B13 1 1 B24 B23 B22 B21 B20 B19
(for Motorola mode)
31 0 1 1 B24 B23 B22 B21 B20 B19 1 1 B18 B17 B16 B15 B14 B13 1 1 B12 B11 B10 B9 B8 B7 1 1 B6 B5 B4 B3 B2 B1
(for Intel mode) where for the 600 bit/s e.g. B1 to B6 belong to the first 10-octet frame, B7 to B12 belong to the second 10-octet frame etc.
User's Manual 121 01.2000
PEB 20320
Functional Description Options The different options for this mode are the framing pattern as shown in Table 2 to Table 5 is programmed by the bits TRV. Interrupts The possible interrupts for this mode are FRC: issued if the receiver has detected a change of S-, X-, E-bits; the value of the bits E7, ..., E1, S8 for SA and S9 for SB and the second occurrence of X within the 10octet frame is reported within the same interrupt. (maskable by CH in the channel specification HI: issued if the HI bit is detected in the transmit descriptor (not maskable). ERR: issued if one of the following receive errors has occurred: - a fast receive abort channel command was issued (this leads to a setting of the RA bit in the status byte) - data could only partly be stored due to internal buffer overflow of RB - 3 consecutive frames had an error in the synchronization pattern (loss of synchronism) - the HOLD bit in the receive descriptor was detected (this leads to a setting of the RA bit in status in the receive descriptor). (maskable by RE in the channel specification) FO: issued if due to inaccessibility of the internal buffer (RB) one or more changes of E-, S-, X-bits and/or loss of synchronism information have been lost. (maskable by RE in the channel specification)
Example V.110/X.30 channel with CS = 0 (required) INV = 0 CRC = 0 TRV = 00 (600 bit/s) FA = 0 MODE = 10 (V.110/X.30) Motorola interface Channel No. D
User's Manual
122
01.2000
PEB 20320
Functional Description
... 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 0 1 0 0 0 1 0 1 1 1 0 0 0 0 0 1 0 1 1 1 1 1 0 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 0 0 0 0 1 0 1 1 1 0 0 0 0 0 1 0 1 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 1 1 1 1 0 0 1 1 0 0 1 0 0 0 0 0 1 1 0 0 1 1 1 1 0 0 0 0 0 0 1 1 1 1 0 0 1 0 0 1 1 1 0 1 0 0 1 1 0 1 1 0 0 0 0 0 1 1 0 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 1 1 1 0 1 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 0 1 0 0 0 1 0 0 0 0 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 0 0 0 1 1 0 1 1 1 1 1 0 1 1 1 0 1 1 1 1 0
MUNICH32 waits for synchronization after reset
1 1 1 0 1 0 0 1 E9 H B6 B5 B4 B3 B2 B1
Reported as X Reported as SA Reported as SB Error in synchronization pattern
1 1 0 0 1 0 1 0 CAH B6 B5 B4 B3 B2 B1
No change of E, S, X Bits
Change of E, S, X Bits; but SA is still reported as '1'
1 1 1 1 1 0 1 0 FA H B6 B5 B4 B3 B2 B1
Reported as SA Error in synchronization pattern
1 1 0 1 0 0 1 0 D2 H B6 B5 B4 B3 B2 B1 No change of E, S, X Bits Error in synchronization pattern
ITS08219
Figure 70a
User's Manual 123 01.2000
PEB 20320
Functional Description
0 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
0 0 1 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
0 0 1 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
0 0 1 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 1 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
0 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
EDH No change of E, S, X Bits
Error in synchronization pattern
FF H
Change of E, S, X Bits
FF H Change of E, S, X Bits
No error in synchronization pattern
C0 H Change of E, S, X Bits
Error in synchronization pattern
ITS08220
Figure 70b
User's Manual 124 01.2000
PEB 20320
Functional Description
8E5B002D 8E5B002D 8800022D 1 Desc 31 00080000 40042000 0
st
8FFF002D 8F57002D 8C00002D 8800202D 2 31
nd
Desc 0
20040000 40040000
Loss of Synch.
31 0 E9 CA FA D2
31 0 ED FF FF C0
ITD05040
Figure 71 For Intel mode the data sections have the form:
of 1st Desc 31 0 D2 FA CA E9
of 2 nd Desc 31 0 C0 FF FF ED
ITD05041
Figure 72
User's Manual
125
01.2000
PEB 20320
Functional Description 2.5 Boundary Scan Unit
In MUNICH32 a Test Access Port (TAP) controller is implemented. The essential part of the TAP is a finite state machine (16 states) controlling the different operational modes of the boundary scan. Both, TAP controller and boundary scan, meet the requirements given by the JTAG standard: IEEE Std. 1149.1. Figure 73 gives an overview.
Test Access Port JTEST0 (TCK) CLOCK Clock Generation CLOCK JTEST1 (TMS) Test Control JTEST2 (TDI) Data IN JTEST3 (TDO) -Finite State Machine -Instruction Register (3 bits) -Test Signal Generator BS Data IN TAP Controller Control Bus 6 ID Data OUT SS Data OUT Data OUT n Power ON Reset Pins 1 2
Enable
Boundary Scan (n Bits)
ITB03509
Reset
Figure 73 Block Diagram of Test Access Port and Boundary Scan Test handling is performed via the pins JTEST0 (TCK), JTEST1 (TMS), JTEST2 (TDI) and JTEST3 (TDO). Test data at JTEST2 (TDI) are loaded with a 4-MHz clock signal connected to JTEST0 (TCK). `1' or `0' on JTEST1 (TMS) causes a transition from one controller state to an other; constant `1' on JTEST1 (TMS) leads to normal operation of the chip. If no boundary scan testing is planned JTEST1 (TMS) and JTEST2 (TDI) do not need to be connected since pull-up transistors ensure high input levels in this case. Nevertheless it would be a good practice to put the unused inputs to defined levels. In this case, if the JTAG is not used: JTEST1 = JTEST0 = `1'. After switching on the device (VDD = 0 to 5 V) a power-on reset is generated which forces the TAP controller into test logic reset state.
User's Manual 126 01.2000
Identification Scan (32 Bits)
PEB 20320
Functional Description Table 6 Boundary Scan Sequence in PEB 20320 JTEST2 (TDI) Pin No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Pin Reset SCLK TEST AR TDATA TSP TCLK I/M B16 Ready/DSACK BERR HLDA/BG HLDAO/BGO BGACK HOLD/BR ADS/AS DS WR/RW BE3 BE2 D0 BE1 D1 BE0 D2 A2 D3 A3 D4 A4 D5 A5 D6 A6 D7 I/O I I I I O I I I I I I I O I/O I/O O O O O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O Number of Boundary Scan Cells 1 1 1 1 2 1 1 1 1 1 1 1 2 3 3 2 2 2 2 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 Constant Value 0 1 1 0 00 0 0 0 0 0 0 0 00 001 010 00 01 00 00 01 100 00 000 00 000 00 000 00 000 00 000 00 000 00 000
User's Manual
127
01.2000
PEB 20320
Functional Description Table 6 Boundary Scan Sequence in PEB 20320 (cont'd) JTEST2 (TDI) Pin 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 A7 D8 A8 D9 A9 D10 A10 D11 A11 D12 A12 D13 A13 D14 A14 D15 A15 D16 A16 D17 A17 D18 A18 D19 A19 D20 A20 D21 A21 D22 A22 D23 A23 D24 A24 I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O I/O O Number of Boundary Scan Cells 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 3 2 Constant Value 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00 000 00
User's Manual
128
01.2000
PEB 20320
Functional Description Table 6 Boundary Scan Sequence in PEB 20320 (cont'd) JTEST2 (TDI) Pin 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 D25 A25 D26 A26 D27 A27 D28 A28/DP0 D29 A29/DP1 D30 A30/DP2 D31 A31/DP3 INT/INT RCLK RSP RDATA CI0 CI1 CI2 CI3 CI4 I/O I/O O I/O O I/O O I/O I/O I/O I/O I/O I/O I/O I/O O I I I I I I I I Number of Boundary Scan Cells 3 2 3 2 3 2 3 3 3 3 3 3 3 3 2 1 1 1 1 1 1 1 1 Constant Value 000 00 000 00 000 00 000 000 000 000 000 000 000 000 00 0 0 0 0 0 0 0 0 JTEST3 (TDO) An input pin (I) uses one boundary scan cell (data in), an output pin (O) uses two cells (data out, enable) and an I/O-pin (IO) uses three cells (data in, data out, enable). Therefore the boundary scan of the MUNICH32 contains a total of n = 205 scan cells. The right column of Table 6 gives the initialization values of the cells. The desired test mode is selected by serially loading a 3-bit instruction code into the instruction register via JTEST2 (TDI) (LSB first); see Table 3.
User's Manual
129
01.2000
PEB 20320
Functional Description Table 7 Boundary Scan Test Modes Instruction (Bit 2 ... 0) 000 001 010 011 111 others Test Mode EXTEST (external testing) INTEST (internal testing) SAMPLE/PRELOAD (snap-shot testing) IDCODE (reading ID code) BYPASS (bypass operation) handled like BYPASS
EXTEST is used to examine the interconnection of the devices on the board. In this test mode at first all input pins capture the current level on the corresponding external interconnection line, whereas all output pins are held at constant values (`0' or `1', according to Table 6). Then the content of the boundary scan is shifted to JTEST3 (TDO). At the same time the next scan vector is loaded from JTEST2 (TDI). Subsequently all output pins are updated according to the new boundary scan contents and all input pins again capture the current external level afterwards, and so on. INTEST supports internal testing of the chip, i.e. the output pins capture the current level on the corresponding internal line whereas all input pins are held on constant values (`0' or `1', according to Table 6). The resulting boundary scan vector is shifted to JTEST3 (TDO). The next test vector is serially loaded via JTEST2 (TDI). Then all input pins are updated for the following test cycle. Note: In capture IR-state the code `001' is automatically loaded into the instruction register, i.e. if INTEST is wanted the shift IR-state does not need to be passed. SAMPLE/PRELOAD is a test mode which provides a snap-shot of pin levels during normal operation. IDCODE: A 32-bit identification register is serially read out via JTEST3 (TDO). It contains the version number (4 bits), the device code (16 bits) and the manufacturer code (11 bits). The LSB is fixed to `1'. JTEST2 (TDI) 0110 0000 0000 0000 0101 0000 1000 001 1 0001 for version 2.1 0010 for version 2.2 0100 for version 3.2 JTEST3 (TDO)
IDCODE for old versions:
Note: As in test logic reset state the code `011' is automatically loaded into the instruction register the ID code can easily be read out in shift DR state which is reached by JTEST1 (TMS) = 0, 1, 0, 0. BYPASS: A bit entering JTEST2 (TDI) is shifted to JTEST3 (TDO) after one JTEST0 (TCK) clock cycle.
User's Manual 130 01.2000
PEB 20320
Operational Description 3 3.1 Operational Description Reset State
Upon reset MUNICH32 is set to its initial state. The active high system reset clears the internal logic and causes MUNICH32 to tristate all output lines. Channel processing is deactivated. After reset all buffers are empty and no buffer size of TB is allocated to the channels. The DMA controller state is set to the hold condition for all link lists. The descriptor and data pointers remain at a random value. The bits RO and TO are set to `1' and RA and TA are set to `0' for all logical channels by reset. All time slots are connected to the logical channel 0 and the following configuration is set: Action Specification LOC = LOOP = LOOPI = 0 PCM = T1/DS1 x 24-channel 1.536 Mbit/s (000) MFL = 0 Time Slot Assignment fill/mask = 00H, i.e. all bits masked/set to `1' RTI, TTI = 0 channel number = 00H Channel Specification MODE = 00, i.e. TMA FA = 0 IFTF = 0 CRC = 0 INV = 0 TRV = 00, RO = 1 RA = 0 TO = 1 TA = 0 TH = 0
User's Manual
131
01.2000
PEB 20320
Operational Description Transmit Descriptor FNUM = 00H, i.e. shared flags in HDLC, only eight zero bits between sent frames for TMB. The E-, S-, X-bits are all set to zero internally by the reset. The receiver is set into the ITF/IDLE state for all channels, i.e. it assumes that on the line there are `1's as interframe time-fill for HDLC. 3.2 Initialization Procedure
After reset MUNICH32 remains in the initial state until the microprocessor generates an action request. In the action specification the initialization sequence is defined. The sequence can be split up into individual procedures of each channel or in one single procedure to initialize all channels at the same time. For all procedures the time slot assignment and the selected channel specifications are loaded into the CSR-RAM. To prevent malfunction the initialization of the link lists and the allocation of the buffer size to the channels has to be specified before the transmission can be started. The interrupt queue must be established as well. MUNICH32 assumes that time slot 0 starts on the receive and transmit lines. They can be resynchronized by 2 rising edges of TSP and RSP respectively. The first rising edge of TSP/RSP should not take place within the first 1000 SCLK clock cycles after deassertion of the reset pin. Before this resynchronization the host should neither remove RO = 1, TO = 1 nor set LOOP or LOOPI to `1' for any logical channel. During this time any incoming data is ignored, the transmit data line tristated. For each action service the device first reads the control start address in the control and configuration section which is located under a fixed address determined by the input signals (CI(4:0)). The values of CI(4:0) can be changed during operation. The values are used after the next falling edge of AR. CI4 CI3 CI2 CI1 CI0 is the polarity of A31 ... A22 is the polarity of A21 ... A16 is the polarity of A15 ... A4 is the polarity of A3 is the polarity of A2 A0, A1 = 0 for example CI(4:0) ADDRESS = = 10101 1111.1111.1100.0000.1111.1111.1111.0100
User's Manual
132
01.2000
PEB 20320
Operational Description
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9
8
7
6
5
4
3
2
1
0
CI4
CI3
CI2
CI1 CI0
00
Figure 74
CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl. Start Addr. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0000 0000 0000 0000 0000 0000 0000 0000 003F 003F 003F 003F 003F 003F 003F 003F 0000 0004 0008
CI4 CI3 CI2 CI1 CI0 Loc. of Ctrl. Start Addr. 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 FFC0 0000 FFC0 0004 FFC0 0008 FFC0 000C FFC0 FFF0 FFC0 FFF4 FFC0 FFF8 FFC0 FFFC FFFF 0000 FFFF 0004 FFFF 0008 FFFF 000C FFFF FFF0 FFFF FFF4 FFFF FFF8 FFFF FFFC
000C 1 FFF0 1 FFF4 1 FFF8 1 FFFC 1 0000 0004 0008 1 1 1
000C 1 FFF0 1 FFF4 1 FFF8 1 FFFC 1
Figure 75 CI-Pin Decoding
User's Manual 133 01.2000
PEB 20320
Detailed Register Description 4 4.1 Detailed Register Description Organization of the Shared Memory
Because the MUNICH32 reads only long words, all addresses of the link lists, interrupt queue and the CCS must be a multiple of four; i.e. the two least significant bits of the address must be `00'. Figure 76 depicts the organization of the shared memory for one MUNICH32.
User's Manual
134
01.2000
PEB 20320
Detailed Register Description
CCBA Control Start Address
Receive DATA Channel 0
Interrupt Circular Queue
Action Specification Interrupt Queue Specification Time Slot 0 Assignment
Receive Descriptor Channel 0 Time Slot 31 Assignment Transmit DATA Channel 0 Receive Descriptor Channel 0 Channel 0 Specification Last 8 Blocks not used in T1/DS1 Mode
Transmit Descriptor Channel 0
Transmit Descriptor Channel 0
Channel 31 Specification Current Receive Descriptor Address Channel 0
Current Receive Descriptor Address Channel 31 Current Transmit Descriptor Address Channel 0
Current Transmit Descriptor Address Channel 31 Control and Configuration Section
ITD03508
Figure 76 Organization of the Shared Memory
User's Manual 135 01.2000
PEB 20320
Detailed Register Description 4.2 Control and Configuration Section
Table 8 Buffer Size of the Control and Configuration Section Control and Configuration Section Action specification Interrupt queue specification Time slot assignment Channel specification Current descriptor address 4.2.1 Number of Long Words 1 2 32 128 64
Action Specification (Read Once After Each Action Request Pulse)
All actions are selected by setting the corresponding bits to `1'. 31 30 PCM 15 14 13 0 12 11 10 9 8 7 6 29 28 27 26 25 24 23 22 21 20 19 18 17 16
MFL
5
4
3
2
1 0
0 0
IN IC0
Channel Number
IM RES LOC LOOP LOOPI IA
PCM: These three bits determine the PCM highway format. 000: T1/DS1 24-channel 1.536 Mbit/s 100: T1/DS1 24-channel 1.544 Mbit/s 101: CEPT 32-channel 110: 4.096-Mbit/s PCM format and even numbered time slots 111: 4.096-Mbit/s PCM format and odd numbered time slots MFL: Maximum Frame Length (up to 8191 bytes); MUNICH32 monitors the frame length of the incoming HDLC, TMB or TMR frames. If the maximum frame length is exceeded an interrupt is generated and the current frame aborted. The length check is active in all modes except transparent mode A and V.110/X.30. Therefore in all other modes one has to write a reasonable value to MFL after reset. MFL is the same for all logical channels.
User's Manual
136
01.2000
PEB 20320
Detailed Register Description IN: Initialization procedure; setting this bit to one causes MUNICH32 to fetch all the time slot assignments and the channel specification of the selected channel (channel number). To avoid collision all time slots being reinitialized should be in a deactivated mode, i.e. the receive and transmit channels must be switched off.
ICO: Initialize Channel Only; only the channel specification of the selected channel (channel number) is read and reconfigured. IM: Interrupt Mask; MUNICH32 suppresses the interrupt normally generated in order to acknowledge the action request.
RES: RESET; a single initialization procedure is performed. The time slot assignment and all channel specifications are written into the CSR. All time slots are reinitialized. Note 1: The bits IN, ICO, RES are mutually exclusive within one action specification. They establish different ways of initializing, configuring and reconfiguring the channels and time slots of the MUNICH32. For test purposes four different loops can be switched at the serial interface with aid of LOC, LOOP, LOOPI according to the following table LOC 0 1 0 1 0 1 0 1 LOOP 0 0 0 0 1 1 1 1 LOOPI 0 0 1 1 0 0 1 1 Interpretation no loop not allowed complete internal loop channelwise internal loop complete external loop channelwise external loop not allowed not allowed
The loops have the following functions: - Complete external loop The serial data input is physically mirrored back to the serial data output. The time and strobe signals for receive and transmit direction have to be identical. - Complete internal loop The serial data output is physically mirrored back to the serial data input. The data on the external input line are ignored. The logical channels have to be programmed identically. The time and strobe signals for receive and transmit direction have to be identical.
User's Manual
137
01.2000
PEB 20320
Detailed Register Description - Channelwise external loop One single logical channel is mirrored logically from serial data input to serial data output. The other channels are not affected by this operation. The data rate for this single logical channel has to be identical for receive and transmit direction. - Channelwise internal loop One single logical channel is mirrored logically from serial data output to serial data input. The other channels are not affected by this operation. The data rate for this single logical channel has to be the same for receive and transmit direction. See Chapter 5.1 and Chapter 5.3.2 for a more detailed discussion of test loops. All loops of the MUNICH32 V3.2 are under complete software control. Loops can be closed and opened via software. Handling of the MUNICH32 V3.2 loops: Switch loops on: RES = IN = ICO = `0' LOC, LOOP, LOOPI PCM, MFL, IM, IA CHANNEL NUMBER for selected loop type don't change the previous values in case of channelwise loops use the selected channel number in case of complete loops use channel number of an active channel.
Switch loops off: RES = IN = ICO = `0' LOC = `0', LOOP = LOOPI = `1' PCM, MFL, IM, IA CHANNEL NUMBER IA:
don't change the previous values use channel number used with the `switch loop on'.
Interrupt Attention; a new interrupt queue is defined by the host. MUNICH32 reads the interrupt queue specification and writes the interrupt information into the new interrupt queue.
User's Manual
138
01.2000
PEB 20320
Detailed Register Description
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Initialization Procedure Read the complete time-slot assignment and the channel spec. of the specified channel (channel number). Initialize Channel Only Only the channel spec. of the selected channel (channel number) is read and reconfigured. Maximum Frame Length Maximum size of a received frame in HDLC, TMB and TMR mode (up to 8192 bytes). A received frame is aborted and an interrupt is generated if the size of a received frame exceeds the MFL value. MFL applies to all channels. PCM Highway Format 000 001 010 011 100 101 110 111 T1/DS1 24 Time-Slots, 1.536 Mbit/s Not Allowed Not Allowed Not Allowed T1/DS1 24 Time-Slots, 1.544 Mbit/s CEPT 32 Time-Slots, 2.048 Mbit/s 4.096 Mbit/s PCM Format, even Time-Slots 4.096 Mbit/s PCM Format, odd Time-Slots
IN ICO
PCM
MFL
0
Channel Number Channel No. Used in conjunction with IN and ICO
IM RES LOC LOOP LOOPI IA
Loops 000 001 010 011 100 101 110 111 Reset Interrupt Mask
00
Interrupt Attention A new interrupt queue has been defined. Read the interrupt queue specification.
No Loop Complete Internal Loop Complete Internal Loop Not Allowed Not Allowed Channelwise int. Loop Channelwise ext. Loop Not Allowed
Read the complete time-slot assignment Read all channel specifications Reinitialize all time-slots
Do not generate the ARACK & ARF interrupt
ITS08221
Figure 77 Action Specification
User's Manual
139
01.2000
PEB 20320
Detailed Register Description 4.2.2 31 0 15 0 Interrupt Queue Specification 30 0 14 0 29 0 13 0 28 0 12 0 27 0 11 0 26 0 10 0 25 0 9 0 24 0 8 0 23 0 7 22 0 6 21 0 5 20 0 4 n 19 0 3 18 0 2 17 0 1 16 0 0
Interrupt Queue Address
Interrupt Queue Address
The interrupt queue is specified as a kind of block (queue), starting on a start address (programmable) with a defined length (programmable). Both, the start address and the queue length are programmable in the Interrupt Queue Specification of the Control and Configuration Section. overwrite START ADDRESS (Interrupt Queue Address)
interrupt information long word 1 interrupt information long word 2 interrupt information long word 3
. . .
length = (n + 1) x 16 long words where 0 n 255
interrupt information long word (n+1)x16
Figure 78 The minimum queue size is 16 long words; the maximum queue size is 4096 long words. For each interrupt arising, the MUNICH32 writes the interrupt information into the interrupt queue, will increment the pointer to the next address in this block automatically and will generate an interrupt pulse at each interrupt occasion. It is up to the processor to read the interrupt informations out of the interrupt queue. If the MUNICH32 arrives at the end of the interrupt queue, it will jump to the start address of the interrupt block again (cyclic queue) and completely overwrite the previous information. Therefore the length of the interrupt queue should be calculated so, that the MUNICH32 will not overwrite information which was not yet read by the processor.
User's Manual
140
01.2000
PEB 20320
Detailed Register Description 4.2.3 Interrupt Information
The next table shows the bit assignments for the interrupt information long word. 31 INT 30 0 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Interrupt Information
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Interrupt Information
Channel Number/Direction
When an interrupt occurs MUNICH32 sets the INT bit and writes the interrupt information and the channel number into the interrupt circular buffer. At the same time it generates an interrupt pulse. The classes of error (for example host initiated interrupt or CRC error) of a channel in one direction are treated independently of each other. If several interrupt events coincide they will be indicated to the host with one shared interrupt. 31 INT 15 30 0 14 29 28 27 26 25 E7 9 24 23 22 21 20 19 18 17 16 X 0
VN3 VN2 VN1 FRC 13 12 FI 11 IFC 10
E6 E5 E4 E3 E2 E1 SB SA 8 7 0 6 0 5 RT 4 3 2 1
ARACK ARF HI
SF ERR FO
Channel Number
Bit assignment for interrupt queue There are 3 classes of bits in the interrupt: 1. Bits present in each interrupt: INT: this bit is always set to `1' VN(3:1): these bits are `000' for version 1.1 `001' for version 2.1 `010' for version 2.2 `100' for version 3.2 `110' for version 3.4
User's Manual
141
01.2000
PEB 20320
Detailed Register Description 2. Action request interrupts ARACK: Action Request Acknowledge; MUNICH32 sets the ARACK bit to indicate that an action request has been serviced. ARF: Action Request Fail; MUNICH32 aborts an ACTION REQUEST, if the required configuration cannot be performed. An action request fail can occur either when the TB buffer is initialized incorrectly or a bus cycle error (BERR = 0) is detected during a configuration access. If ARACK or ARF is set, all bits except INT and VN(3:1) are set to 0. Note: An action request is forbidden during the time a preceding action has not been finished by an ARACK or ARF interrupt or a pulse at the reset pin. 3. Channel specific interrupts These interrupts indicate specific events in the channel indicated by `Channel Number' and receive or transmit direction indicated by RT (RT = `1': receive direction; RT = `1': transmit direction). The interpretation of these interrupts depends on the specification of the channel in which they occur. The following table shows which interrupts can occur in which mode (unused bits are always 0). 31 INT 30 0 29 28 27 26 25 E7 0 R 0 0 10 SF TR TR TR TR 24 E6 0 R 0 0 9 ERR 23 E5 0 R 0 0 8 FO 22 E4 0 R 0 0 7 0 0 0 0 0 6 0 X X X X 21 E3 0 R 0 0 5 RT X X X X 20 E2 0 R 0 0 4 19 E1 0 R 0 0 3 18 17 16 X 0 R 0 0 0
VN3 VN2 VN1 FRC F F F F 14 ARF TR TR TR TR F F F F 13 HI F F F F 12 FI 0 R 0 0 11 IFC R 0 0 0
SB SA 0 R 0 0 2 0 R 0 0 1
HDLC 1 0 V.110/X.30 1 0 TMA 1 0 TMB/TMR 1 0 15 ARACK HDLC G G V.110/X.30 G G TMA G G TMB/TMR G G
Channel Number X X X X X X X X X X X X X X X X
TR R 0 T 0 0
TR 0 TR 0 TR 0 TR 0
TR 0
User's Manual
142
01.2000
PEB 20320
Detailed Register Description Where `1' `0' `F' `R' means that the bit is always `1' for this mode means that the bit is always `0' for this mode means the bit is fixed by the version number means a bit that can only be set in the receive direction, i.e. may only be `1' if RT is `1' `T' means a bit that can only occur in transmit direction, i.e. may only be `1' if RT is `0' `TR' means a bit that can occur in receive or transmit direction `G' means a bit of an activation request interrupt which cannot be `G' in a channel specific interrupt `X' means a bit fixed by the channel and direction (receive, transmit) of the event it belongs to.
The meaning of the interrupt bits depend on the mode. We therefore will discuss them bit for bit and indicate the different meanings in the different modes. FRC: (V.110/X.30 mode, receive direction only) Change of the framing (E, S, X) bits of the V.110/X.30 frame detected. This interrupt is generated whenever a change in the E-, S-, X-bits is detected, but at most one time within one frame of 10 octets, even if there is more than one change within the frame. After detecting a receive abort channel command for one 10-octet frame FRC is also issued. (V.110/X.30 mode, receive direction only, only in conjunction with FRC) The value of the bits Ex, Sx, X in the received V.110/X.30 frame. If a value changes, e.g. 2 times within the same frame only the final change is reported. If the change was caused by a receive abort channel command all bits are 0. (all modes, all direction) Host initiated Interrupt; this bit is set when the MUNICH32 detects the HI bit in the receive or transmit descriptor and branches to the next descriptor, or starts polling the hold bit if set. 1.1 HDLC, TMB, TMR Receive Direction: FI = 1 indicates, that a frame has been received completely or was stopped by a receive abort channel command or fast receive abort or a HOLD in a receive descriptor. It is set when the MUNICH32 branches from the last descriptor belonging to the frame to the first descriptor of a new frame. It is also set when the descriptor in which the frame finished contained a hold bit, the interrupt is then issued when the MUNICH32 starts polling the hold bit. 1.2 HDLC, TMB, TMR, TMA Transmit Direction: issued if the FE bit is detected in the transmit descriptor. It is set when the MUNICH32 branches to the next transmit descriptor, belonging to a
User's Manual 143 01.2000
Ex, Sx, X:
HI:
FI:
PEB 20320
Detailed Register Description new frame, or when it starts polling the hold bit if set in conjunction with the FE bit; ERR and FI are set if a transmit descriptor contains a HOLD bit no FE bit IFC: (HDLC mode, receive direction only) Idle/Flag Change; an interrupt is generated in HDLC if the device changes the interframe time-fill (ITF) state. After reset the device is in the ITF idle state. It changes to the ITF flag state if it receives 2 consecutive flags with or without shared zeroes. It changes back to the ITF idle state upon reception of 15 contiguous `1'-bits or when a receive abort channel command is active during 15 received bits. (HDLC mode, receive direction only, always in conjunction with FI) Short frame detected A frame with 16 bits between start flag and end flag or end abort flag for CRC16 32 bits between start flag and end flag or end abort flag for CRC32 has been detected. The sequences 7E 7FH and 7E FEH and 7E FFH are also short frames. SF is always in conjunction with ERR except for the frames 7E00 007EH for CRC16 7E00 0000 007EH for CRC32 always in conjunction with FI = 1 1.1 HDLC mode Receive Direction One of the following receive errors occurred - FCS of the frame was incorrect - the bit length of the frame was not divisible by 8 - the byte length exceeded MFL - the frame was stopped by 7FH - the frame could only be partly stored due to internal buffer overflow of RB - the frame was ended by a receive abort channel command - the frame could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the frame. - the frame was aborted by a fast receive abort channel command A more detailed error analysis can be done by the status information in the receive descriptor. 1.2 HDLC mode Transmit Direction one of the following transmit errors occurred: - the last descriptor had HOLD = 1 and FE = 0 - the last descriptor had NO = 0 and FE = 0
SF:
ERR:
User's Manual
144
01.2000
PEB 20320
Detailed Register Description 2.1 V.110/X.30 mode Receive Direction one of the following receive errors occurred: - data could only partly stored due to internal buffer overflow of RB - 3 consecutive frames had an error in the synchronization pattern (loss of synchronism) - a fast receive abort channel command was issued - the data could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the data - a receive abort channel command was active for at least 3 consecutive frames A more detailed error analysis can be done by the status information in the receive descriptor. 2.2 V.110/X.30 mode Transmit Direction one of the following transmit errors occurred - the last descriptor had a HOLD = 1 or FE = 1 - the last descriptor had FE = 0 and NO = 0 3.1 TMA mode Receive Direction one of the following errors occurred - the data could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the data - a fast receive abort channel command was issued 3.2 TMA mode see Chapter 1.2 Transmit Direction
4.1 TMB/TMR mode Receive Direction always in conjunction with FI = 1 one of the following receive errors occurred - the bit length of the frame was not divisible by 8 - the frame could only be partly stored due to internal buffer overflow of RB - the frame could not be transferred to the shared memory completely because of a hold bit set in a receive descriptor not providing enough bytes for the frame - the frame was aborted by a fast receive abort channel command A more detailed error analysis can be done by the status information in the receive descriptor. 4.2 TMB/TMR mode see 1.2 FO: Transmit Direction
1.1 HDLC, TMB, TMR Receive Direction The MUNICH32 has discarded one or more whole frames or short
145 01.2000
User's Manual
PEB 20320
Detailed Register Description frames or change of interframe time-fill informations due to inaccessibility of the internal buffer RB. 1.2 HDLC, TMB, TMR Transmit Direction The MUNICH32 is unable to access the shared memory in time or has detected a bus cycle error (BERR = 0) during a read access on the transmit data section. The current erroneous frame is aborted with a `0' and 14 `1' for HDLC, with 00 for TMB and 0000 for TMR; afterwards interframe time fill is sent until the MUNICH32 can access again the shared memory. The MUNICH32 will read the transmit data from the location which should be accessed before the Tx-FO or BERR happened and transmit the rest of the erroneous frame. 2.1 V.110/X.30 Receive Direction The MUNICH32 has discarded a loss of synchronism information or a change of a E-, S-, X-bits information due to inaccessibility of the internal buffer RB. 2.2 V.110/X.30 Transmit Direction The MUNICH32 is unable to access the shared memory in time or has detected a bus cycle error (BERR = 0) during a read access on the transmit data section. It generates 3 10-octet frames with framing errors and restarts with the next error-free transmit data. 3.1 TMA Receive Direction The MUNICH32 has discarded data due to inaccessibility of the internal buffer RB. 3.2 see Chapter 1.2 The following table shows which interrupt bits are masked by which bits in the channel specification. 31 INT 30 29 28 27 26 25 24 23 22 21 20 19 18 SB 17 SA 16 X
VN3 VN2 VN1 FRC
E7 E6 E5 E4 E3 E2 E1
CH -
Receive Transmit
15
14
13
12 FI
11 IFC
10
9
8
7 0
6 0
5 RT
4
3
2
1
0
ARACK ARF HI Receive
SF ERR FO RE TE
146
Channel Number
FIR IFC SFE RE Transmit FIT
User's Manual
-
-
TE
01.2000
PEB 20320
Detailed Register Description General IM IM
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5
4
3
2
1
0
FRC E7 E6 E5 E4 E3 E2 E1 SB SA X ARACK ARF HI FI IFC SF ERR F0
INT
Framing Bits Changed V.110/X30 mode received E, S, X Bits changed Action Request Acknowledge Action request has been completed successfully. Action Request Failed Action request could not be completed successfully. Silicon Version Number 000 001 010 100 V1.1 V2.1 V2.2 V3.2 Direction
RT
0 VN(3...1)
00
Channel Number Channel Number Identifies the channel where the interrupt occured.
0 Transmit Interrupt 1 Receive Interrupt Overflow/Underflow Internal buffer not available Protocol Error e.g. CRC error, frame aborted, loss of sync. MFL exceeded Internal buffer overflow/underflow Short Frame
Host Initiated Interrupt HI Bit in the Rcv./Xmt. descriptor was set
HDLC mode, in conjunction with FI (empty HDLC frame or incorrect HDLC frame, nothing stored in memory)
Frame Indication Interframe Timefill Change End of receive or transmit frame indication HDLC receiver detected change in ITF state Valid Interrupt Entry MUNICH32 sets this Bit with every entry to the interrupt circular queue Software should dear this Bit after reading
ITS08222
Figure 79 Interrupt Information
User's Manual
147
01.2000
PEB 20320
Detailed Register Description 4.2.4 Time Slot Assignment
(Read only once after each action request pulse with an action specification with set IN or RES bit) The time slot assignment provides the cross reference between the 32 (24) time slots of the PCM highway and the data channels (up to a maximum number of 32). The data channels can be composed of different receive and transmit time slots, which have individual bit rates. With the concept of subchanneling, MUNICH32 can realize flexible transmission from 8 kbit/s up to 2.048 Mbit/s per channel. 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 0 0 0 0 TTI TTI Transmit Channel Number Transmit Channel Number Transmit Fill Mask Transmit Fill Mask time slot 0 time slot 1
0
0
TTI
Transmit Channel Number 9 8 7 6
Transmit Fill Mask
time slot 31
15 14 13 12 11 10 0 0 0 RTI 0 RTI
5
4
3
2
1
0 time slot 0 time slot 1
Receive Channel Number Receive Channel Number
Receive Fill Mask Receive Fill Mask
0
0 RTI
Receive Channel Number
Receive Fill Mask
time slot 31
Fill/Mask Code:
For bit rate adaption the fill/mask code determines the number of bits and the position of these bits within the time slot. For all modes except TMA the bits selected by Fill/Mask = 1 in the slots of a channel are concatenated, those with Fill/Mask = 0 are ignored/tristated in receive/transmit direction. For TMA the bits with Fill/Mask = 0 are received as `1'-bits, in transmit direction these bits are overwritten with `Z' (see Chapter 2.4 for more details).
User's Manual
148
01.2000
PEB 20320
Detailed Register Description Channel Number: The channel number identifies the data channel. Its transmission mode is described in the respective channel specification. TTI: Transmit Time slot Inhibit; setting this bit to `1' causes MUNICH32 to tristate the transmit time slot. The data is not destroyed but sent in the next not tristated time slot allocated to this channel. Receive time Slot Inhibit; setting this bit to `1' causes MUNICH32 to ignore the received data in the time slot. The channel is not processed in this time slot. Channel Specification
RTI:
4.2.5
(Read only once after each activation request pulse with an action specification with set IN, RES or ICO bit; RES: the channel specifications of all channels; IN, IC0: the channel specification of the channel indicated in the action specification) 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
Interrupt Mask
NITBS RI FRDA FTDA
TI
TO
TA
TH RO RA
0
0
0
0
0
0 9
0
0 8
0 7
0 6
0 5
0 4
0 3
0 2
0 1
0 0
15 14 13 12 11 10
TFLAG
TFLAG TFLAG /NSF /CS INV FRDA FTDA
CR C
TRV
FA
Mode
IFT F
0
0
0
0
0
0
0
0
0
0
ITBS
Interrupt Mask: 7 - 6 SFE 5 IFC 4 CH 3 TE 2 RE 1 FIR 0 FIT
These bits mask the bits in the interrupt information long word according to the table at the end of Chapter 4.2.3 (interrupt information).
User's Manual
149
01.2000
PEB 20320
Detailed Register Description If an event leads to an interrupt with several bits set (e.g. FI and ERR) masking only a proper subset of them (e.g. ERR) will lead to an interrupt with the nonmasked bits set (e.g. FI). If all bits of an event are masked, the interrupt is suppressed. The interrupt mask is therefore bit specific and not event specific. NITBS: New ITBS value; if this bit is set the individual transmit buffer size ITBS is valid and a new buffer field of TB is assigned to the channel. In this process first the occupied buffer locations of the channel are released and then according to ITBS a new buffer area is allocated. If there is not enough buffer size in TB (occupied by other channels) the process will be aborted and an action request failure interrupt is generated. After aborting no buffer size is allocated to the channel. For preventing action request failure enough buffer locations must be available. This can be done by reducing the buffer size of the other channels. To avoid transmission errors all channels to be newly configured must be deactivated before processing. Note: ITBS has to be set to `0' if NITBS = `0'. NITBS should be set to `0' in conjunction with a transmit abort channel command. The bits RI, TI, TO, TA, TH, RO, RA are the so called channel command bits. They allow the channel to be initialized, aborted or reconfigured at the serial side as well as at the P side. These bits can be decomposed in 3 independent command groups: RI, RO, RA form the receive command group TO, TI, TA the first transmit command group and TH is the second transmit command group. We will discuss these bits according to the groups. 1. Receive command group (6 commands) - receive clear RI = 0, RO = 0, RA = 0 (clears a previous receive abort or receive off condition, affects only the serial interface) The effect of this command depends on the previous history of the channel * if the channel was never initialized by a receive initialization command it has no effect * if it was initialized previously it clears a receive off or receive abort condition set by a previous channel command * if no receive off or receive abort condition is set it has no effect. - fast receive abort RI = 0, RO = 0, RA = 1 (clears a previous receive abort or receive off condition, affects only the DMA interface) This abort is performed in the DMA controller and does not interfere with the reception on the serial interface and the transfer of the data into the receive buffer. If this abort is detected the current receive descriptor is suspended with an abort status (RA bit set
User's Manual 150 01.2000
PEB 20320
Detailed Register Description to `1') followed by a branching to the new descriptor (FRDA) defined in the channel specification of the CCS. For HDLC, TMB, TMR the rest of a frame which was only partially transferred before suspension of the receive descriptor is aborted, the new descriptor is related to the next frame. An interrupt with FI, ERR is issued. For V.110/X.30 and TMA data bits might get lost. An interrupt with ERR is issued. - receive off RI = 0, RO = 1, RA = 0 (clears a previous receive abort condition, sets off condition, affects only the serial interface) This channel command sets the receiver into the receive off condition. The receive channel is disabled completely at the serial interface, i.e. the receive deformatter RD is reset and the receive buffer RB is not accessed for this channel. A currently processed frame (HDLC, TMB, TMR mode) is not properly finished with any status information. The data stored in the RB at that time is still transferred to the shared memory. After the receive off condition is cleared by another channel command: * in HDLC, TMB, TMR (V.110/X.30, TMA) mode the device waits for a new frame (10octet frame, nothing) to begin and then starts filling RB again. If the receive off command lead to an improper finishing of a frame (data, data), the new frame (data, data) is concatenated with the finished one. To avoid this problem there are two suggestions: a) issue a receive abort channel command and wait for 32 (240, 8) bits for this channel to be processed before issuing the receive off command. b) wait in the receive off condition until the RB is emptied for this channel (i.e. for at most 8 PCM frames if the MUNICH32 has sufficient access to the shared memory) and leave the receive off condition by a receive initialization command. The receive off channel command is ignored in case of any kind of loop. - receive abort RI = 0, RO = 1, RA = 1 (clears a previous receive off condition, sets a receive abort condition, affects only the serial interface) This receive channel command sets the receiver into the receive abort condition. In this condition it receives (instead of the normally received bits) logical `1' bits for HDLC logical `0' bits for V.110/X.30, TMB, TMR logical `0' bits for unmasked bits in TMA mode logical `1' bits for masked bits in TMA mode irrespective of the INV bit. This leads to * For HDLC: a currently processed frame is aborted after 7 received bits for this channel, leading to a RA set in the status of the frame and an interrupt with set FI and ERR bits only or to an interrupt with set SF, FI and ERR bits. If the receiver was
User's Manual
151
01.2000
PEB 20320
Detailed Register Description in the flag interframe time-fill state it will lead to an interrupt with set IFC bit after 15 received bits. For V.110/X.30: if the receiver was in the synchronized frame state it will go to the unsynchronized state after 240 bits and issue a LOSS bit in the status of the current receive descriptor. It will also issue an interrupt with set ERR bit and (unless all E-, S-, X-bits were 0 previously) issue one or two interrupts with FRC set and having all E-, S-, X-bits at 0 in the last one. For TMB: a currently processed frame is aborted after 15 received bits for this channel, leading to an interrupt with FI set but ERR on 0, the status of this frame is always 00H. For TMR: a currently processed frame is aborted after 31 received bits for this channel, leading to an interrupt with FI set but ERR on 0, the status of this frame is always 00H. For TMA: the device receives the inverse of the fill/mask bits programmed for this channels.
*
*
*
*
Note 1: It is advisable to clear the receive abort condition via a receive off command for V.110/X.30 mode, the TMB and the TMR mode. 2. After issuing a receive abort channel command it is advisable to stay in this condition during at least 16, 240, 16, 32, 8 bits of the channel for HDLC, V.110/ X.30, TMB, TMR, TMA respectively. - receive jump RI = 1, RO = 0, RA = 0 (clears a previous receive abort or receive off condition, affects only the DMA interface) During normal operation branching to a new descriptor (FRDA) is possible without interrupting the current descriptor and aborting the received frame (HDLC, TMB, TMR) or received data (V.110/X.30, TMA). The DMA controller will proceed finishing the current receive descriptor as usual either with a frame end condition or with the corresponding data buffer completely filled and afterwards branch to the new descriptor specified by FRDA. Thus a received frame may be splitted on `old' and `new' descriptors. - receive initialization RI = 1, RO = 0, RA = 1 (clears a previous receive abort or receive off condition, affects the DMA and serial interface) Before the MUNICH32 has got a receive initialization command it will not receive anything properly in a channel. This command should therefore be the first channel command after a pulse at the reset pin for a channel to be used. FRDA is then the address of the starting point of the receive descriptor chaining list. If the command is issued during normal operation it only affects the DMA interface. The current receive descriptor is suspended without writing the second long word with the status, no interrupt is generated. For HDLC, TMB, TMR the rest of a frame which was only partially transferred before the suspension of the receive descriptor is
User's Manual
152
01.2000
PEB 20320
Detailed Register Description aborted, the new descriptor (FRDA) is related to the next frame. For V.110/X.30 and TMA data bits might get lost. General Notes to Receive Commands: 1. After a pulse at the reset pin a channel having a time slot with RTI = 0 should be issued receive off commands until it is supposed to be used. 2. When it is supposed to be used it should be issued a receive initialize command before using any other receive channel command. 3. To shut down a channel in receive direction one should first set it into the receive abort condition for the time specified there and then set it into the receive off condition. 4. Before changing the MODE, CRC, CS, TRV, INV, TFLAG bits of a channel or its RTI or time slot assignment or its fill/mask bits it should have been shut down. The bits should be changed while issuing the receive off command. 5. To revive a channel after it has been shut down one should use the receive initialization command. 6. To switch to a new starting point of a receive descriptor chain one should preferably use the receive jump command, only exceptionally the fast receive abort command and never the receive initialize command. 7. To issue channel commands not affecting the receive side one should issue - a receive clear command if neither a receive off nor a receive abort condition is set - a receive off command if a receive off condition is set - a receive abort command if a receive abort condition is set. 8. Combinations of the bits RI, RO, RA not in this description are reserved and are not allowed to be used. 2. First Transmit Command Group - transmit clear TI = 0, TO = 0, TA = 0 (clears a previous transmit abort or transmit off condition, affects only the serial interface) * if the channel was never initialized by a transmit initialization command it has no effect * if it was initialized previously it clears a transmit off or transmit abort condition set by a previous channel command * if no transmit off or transmit abort condition is set it has no effect - fast transmit abort TI = 0, TO = 0, TA = 1 (clears a previous transmit abort or transmit off condition, affects only the DMA interface) This abort is performed in the DMA controller and does not interfere with the current transmission on the serial interface and the transfer between the TF and TB. If this abort is detected the current descriptor is suspended and the frame or data transferred to the TB is aborted. The next frame beginning in the transmit descriptor (FTDA) defined in the channel specification of the CCS will be started immediately.
User's Manual 153 01.2000
PEB 20320
Detailed Register Description For HDLC, TMB, TMR the first part of the frame of the suspended descriptor is sent and append by 011 1111 1111 111 for HDLC at least 00H for TMB at least 00 00H for TMR Afterwards the next frame is started. For V.110/X.30 three 10-octet frames with errors in the synchronization pattern are sent after the data of the suspended descriptor, afterward the next data are sent in correct frames. For TMA a TFLAG (FA = 1) or FFH (FA = 0) is sent in at least one time slot after the data of the suspended descriptor, afterwards the next data are sent. - transmit off TI = 0, TO = 1, TA = 0 (clears a previous transmit abort condition, sets a transmit off condition, effects only the serial interface) The transmit channel is disabled immediately, i.e. the transmit formatter is reset and the transmit buffer is not accessed for this channel. The output time slots are tristated. Upon leaving the transmit off mode the transmit link list must be initialized by a transmit reinitialize command. Otherwise the transmission will be started with the remaining data still stored in TB and continue with the old link list. If a loop condition is set the transmit off does not reset the transmit formatter, it only tristates the serial output line. After the transmit off condition is cleared by the transmit initialize command. * In HDLC, TMB, TMR, V.110/X.30 the device starts with the interframe time-fill 7E for HDLC and IFTF = 0 FF for HDLC and IFTF = 1 00 for TMB, TMR, V.110/X.30 and then with the frame in the descriptor at FTDA. For V.110/X.30 this descriptor must have the V.110-bit set and point to the E-, S-, X-bits, the data are then at the next transmit descriptor. * In TMA mode the device starts with the interframe time-fill TFLAG for FA = 1 for FA = 0 FFH and then with the data in the descriptor at the FTDA.
User's Manual
154
01.2000
PEB 20320
Detailed Register Description - transmit abort TI = 0, TO = 1, TA = 1 (clears receive off condition, sets transmit abort condition, affects only the serial interface) This abort is performed in the transmit formatter at the serial interface. The currently transmitted frame is aborted by 011 1111 1111 1111 for HDLC for TMB 00H for TMR 0000H 3 frames with erroneous synchronization pattern for V.110/X.30 TFLAG for TMA, FA = 1 FF for TMA, FA = 0. Afterwards or - if no frame is currently sent directly inter frame time fill: 7E for HDLC and IFTF = 0 FF for HDLC and IFTF = 1 00 for TMB, TMR, V.110/X.30 TFLAG for TMA, FA = 1 FF for TMA, FA = 0 is sent. During transmit abort the TF does not access the transmit buffer. The handling of the link list is not affected by the transmit abort, i.e. the device keeps the TB full. When the transmit abort is withdrawn the transmit formatter continues the transmission with the data stored in TB. In the case of HDLC or TMB or TMR mode the remaining data of the aborted HDLC or TMB frame is sent as a new independent frame. To avoid this problem the link list must be reinitialized by a transmit initialization command together with the revoking of the transmission abort. Another proper use of the transmit abort command consists in setting the last descriptor of the last frame to be transmitted with HOLD = 1 and waiting for the device to poll the HOLD bit (ITBS + 2) times where ITBS is the number of long words assigned to this channel currently. Afterwards TB is empty and the transmit abort then issued does not abort a currently sent frame. The same procedure can also be used for the transmit off command. - transmit jump TI = 1, TO = 0, TA = 0 (clears a transmit off and transmit abort condition, affects only the DMA interface) This bit is set only during normal operation. Then MUNICH32 branches to the transmit descriptor (FTDA) specified in the CCS after finishing the current transmit descriptor without interrupting or aborting the transmitted frame. The DMA controller will proceed finishing the current transmit descriptor as usual and afterwards branch to the new descriptor specified by FTDA. If the current descriptor does not include a frame end (FE = 0) (HDLC, TMB, TMR) the DMA controller will link the following data section(s) of the `new' descriptor chain to the opened frame. This may generate unexpected frames.
User's Manual
155
01.2000
PEB 20320
Detailed Register Description - transmit initialization TI = 1, TO = 0, TA = 1 (clears a previous transmit abort condition, affects the DMA interface and the serial interface) Before the MUNICH32 has got a transmit initialization command it will not transmit anything properly in the channel. This command should therefore be the first channel command after a pulse at the reset pin for a channel to be used. FTDA is then the address of the starting point of the transmit descriptor for chaining list. In this case the transmit initialize command should be accompanied by the NITBS bit set and a reasonable value for ITBS (0 < ITBS < 64). If the command is issued during normal operation it only affects the DMA. The MUNICH32 stops processing of the current link list and branches to the transmit descriptor at the FTDA address. The data stored in the TB are discarded and the TB is filled with the data of the new descriptor. 3. Second Transmit Command Group - Transmit HOLD TH; setting this bit causes the device to finish transmission of the current frame (HDLC, TMB, TMR mode) the current data (TMA -mode) or leads to an abort with 3 frames with `0'-bits (V.110/X.30-mode). Afterwards for HDLC mode and IFTF = 1 FFH fill characters HDLC mode and IFTF = 0 7EH fill characters V.110/X.30-mode 00H fill characters TMA mode and FA = 1 TFLAG fill characters TMA mode and FA = 0 FFH fill characters TMB/TMR 00H fill characters are sent until TH is withdrawn by a further action specification affecting the channel specification of this channel. Afterwards no further access to the TB from TF is done, therefore no further data are fetched from the shared memory and the polling of a possible hold bit in the transmit descriptor stops. To send necessary frames/data before the transmit hold is active one should use the proper procedure described under the transmit abort command. General Notes to Transmit Commands: 1. After a pulse at the reset pin a channel having a time slot with TTI = 0 should be issued transmit off commands and TH = 1 until it is supposed to be used. 2. When it is supposed to be used it should be issued a transmit initialization command and TH = 0 before using any other transmit channel commands (together with NITBS = 1, ITBS 0). 3. To shut down a channel in transmit direction one should first set it into the transmit abort condition or use the TH bit with the proper procedure. One should leave it in
User's Manual
156
01.2000
PEB 20320
Detailed Register Description that condition for 32, 240, 32, 32, 8 bits for HDLC, V.110/X.30,TMB, TMR, TMA respectively and then set it into the transmit off condition. Before changing the MODE, CRC, CS, TRV, INV, TFLAG bits or TTI or time slot assignment or the fill/mask bits or the ITBS the channel should be shut down. The bits should be changed while issuing the transmit off command. To revive a channel after it has been shut down one should use the transmit initialization command. For V.110/X.30-mode the first descriptor after reviving from shut down or initialization after reset must have the V.110-bit set and contain the E-, S-, X-bits. To switch to a new starting point of a transmit descriptor chain one should preferably use the transmit jump command, only exceptionally the fast transmit abort command and never the transmit initialize command. To issue channel commands not affecting the transmit side one should issue - TH with the last set value - a transmit clear command if neither a transmit off nor a transmit abort condition is set - a transmit off if a transmit off condition is set - a transmit abort if a transmit abort condition is set. Bit combinations in the first transmit command group not described are reserved. Set NITBS = 1 preferably in conjunction with a transmit initialize and transmit clear command if TB is to be newly configured, otherwise set NITBS = 0. Transparent mode Flag; these bits are only used in the transparent mode A and constitute the fill code for flag stuffing and for flag filtering. These bits must be set to `0' if subchanneling is used in transparent mode A. Bit No. 15 is the first bit of the flag to be received/transmitted. No Short Frame suppression; NSF = 1 is only allowed in combination with HDLC mode and CS = 1. In this mode the MUNICH32 transfers all data to the shared memory even if only one byte (or more) per `frame' is received. No short frame interrupt and no short frame status bit will be generated in this case. Note:CRC is still calculated and checked and e.g. a frame of 1 or 2 byte length (in CRC16 mode) will always cause an FI + ERR interrupt.
4.
5. 6. 7.
8.
9. 10.
TFLAG:
NSF:
User's Manual
157
01.2000
PEB 20320
Detailed Register Description Receive Frame Examples: a) 0x7E, data byte, 0x7E - data byte copied to shared memory + frame end - status SF-bit set - no SF indication interrupt generated - FI indication interrupt generated - ERR interrupt generated due to wrong CRC' b) 0x7E, data byte = 0xFC (or 0xFD or 0x7F), 0x7E - no data byte copied to shared memory - SF and FI interrupt generated CS: CRC Select; only used in HDLC mode. Setting this bit to `1' causes the MUNICH32 to transfer the CRC bits to the data section in the shared memory. In receive direction the CRC check is carried out whereas in transmit direction the CRC generation is suppressed, see Chapter 2.4 for more details. Inversion; If this bit is set, all data of the channel transmitted or received by the MUNICH32 is inverted. Cyclic Redundancy Check; in HDLC mode this bit determines the CRC generator polynomial: When the CRC bit is set to `1' the 32-bit CRC is performed, otherwise the 16-bit CRC; for TMB/TMR mode this bit distinguishes: TMB: CRC = `0' TMR: CRC = `1' for all other modes this bit has to be set to `0'.
INV: CRC:
User's Manual
158
01.2000
PEB 20320
Detailed Register Description TRV: Transmission Rate of V.110/X.30. These signals determine the number of repeated D-bits in a V.110/X.30 frame. Table 9 TRV 00 01 10 11 No. of Repetitions 7 3 1 0 Transmission Rate 600 bit/s 1200 bit/s 2400 bit/s 4.8, 9.6, 19.2, 38.4 kbit/s
Note: In the other modes these bits must be set to `00'. FA: Flag Adjustment selected (in HDLC mode) or flag filtering (selected in transparent mode A only if all fill/mask bits of the corresponding slots are `1'). In all other modes this bit must be set to `0'. If flag adjustment is selected in HDLC mode the number of interframe time-fill characters is FNUM minus one eighth of the number of zero insertions in the frame proceeding the interframe time-fill and belonging to the same transmit descriptor as FNUM. If flag filtering is selected and fills a physical time slot in transparent mode A the flag specified in TFLAG is recognized and extracted from the data stream. In transmit direction the flag TFLAG is sent in all exception conditions, i.e. abort, idle state etc.; if flag filtering is not selected `1'-bits are sent in this case. Flag filtering is only allowed if all fill/mask codes are set to `1', i.e. subchanneling is not allowed. If flag filtering is not selected the bits in TFLAG have to be set to 0 for TMA. Defines the transmission mode: 11: HDLC mode 10: V.110/X.30 mode 00: Transparent mode A 01: Transparent mode B or transparent mode R. Interframe Time-Fill: this bit determines the interframe HDLC mode: IFTF = 0:AEH characters are sent as interframe time-fill IFTF = 1:FFH characters are sent as interframe time-fill. time-fill for
MODE:
IFTF:
FRDA:
First Receive Descriptor Address points to the beginning of the receive data chaining list. This descriptor is only interpreted with a fast receive abort or a receive jump or a receive initialization command. It is read but ignored with any other receive channel command.
User's Manual
159
01.2000
PEB 20320
Detailed Register Description FTDA: First Transmit Descriptor Address points to the beginning of the transmit data chaining list. This descriptor is only interpreted with a fast transmit abort or a transmit jump or a transmit initialization command. It is read but ignored with any other transmit channel command. Individual Transmit Buffer Size; for undisturbed transmission an on-chip transmit buffer with a total size of 64 long words stores the data before formatting and transmitting. The individual buffer size specifies the part of the on chip transmit buffer allocated to the channel. This allows a variable data buffer size if NITBS = 0, ITBS has to be set to 0 also; it is then read but ignored. (see Chapter 2.3).
ITBS:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SFE IFC CH TE RE FIR FIT NITBS RI TI TO TA TH RO RA
CS INV CRC
FRDA (First Receive Descriptor Address) FTDA (First Transmit Descriptor Address) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ITBS (buffer size) New ITBS Value Rcv./Xmt. Commands Transparent Mode Flags Interframe Rcv. Commands Timefill New Xmt. buffer size Fill code for flags in 0 7E (flags) (ITBS valid) (RI, RO, RA): transp. mode A (TMA only) 000 Rcv. Clear 1 FF (ones) 001 Fast Rcv. Abort (HDLC mode) Interrupt Mask CRC Select 010 Rcv. OFF SFR: Short Frame (R) CRC Generated/Stripped 0 011 Rcv. Abort Mode CRC to/from Data Section 1 IFC: Idle/Flag Change (R) 100 Rcv. Jump (HDLC mode only) CH: V.110 Frg. Chg. (R) 0 0 TMA 101 Rcv. Init. TE: ERR Interrupt (T) 0 1 TMB/TMR 110 Not Allowed RE: ERR Interrupt (R) 1 0 V.110/X30 Inversion 111 Not Allowed FIR: FI Interrupt (R) 1 1 HDLC Mode All Rcv. and Xmt. data Bits FIT: FI Interrupt (T) First Xmt. Commands in this channel are inverted. (R) Receiver Interrupt Flag Adjustment/Filtering (T) Transmitter Interrupt (TI, TO, TA): FNUM interframe timefill CRC Polynom 000 Xmt. Clear characters in HDLC mode, 001 Fast Xmt. Abort 16 Bit CRC (HDLC mode) 0 or TFLAG filtering in TMA 010 Xmt. OFF 32 Bit CRC (HDLC mode) 1 011 Xmt. Abort TMB 0 100 Xmt. Jump TMR 1 Transmission Rate of V.110/X30 101 Xmt. Init. 0 0 600 bit/s, 7 Repetitions 110 Not Allowed 0 1 1200 bit/s, 3 Repetitions 111 Not Allowed 1 0 2400 bit/s, 1 Repetitions 1 1 4.8, 9.6, 19.2, 38.4 kbit/s, 2 nd Xmt. Commands no Repetition (TH = 1) : Xmt. Hold
ITS08223
Figure 80 Channel Specification
User's Manual 160 01.2000
FA
0
TFLAG
TRV
Mode
IFTF
PEB 20320
Detailed Register Description 4.2.6 31 Current Receive and Transmit Descriptor Address 16 15 Current Receive Descriptor Address Channel 0 . . . Current Receive Descriptor Address Channel 31 Current Transmit Descriptor Address Channel 0 . . . Current Transmit Descriptor Address Channel 31 For easier monitoring of the link lists the addresses of the just processed descriptors are written into the CCS. MUNICH32 changes the current descriptor address at the same time when it branches to the next descriptor. 0
User's Manual
161
01.2000
PEB 20320
Detailed Register Description 4.3 31 Transmit Descriptor 30 29 28 27 26 25 24 23 22 NO Transmit Data Pointer Next Transmit Descriptor Pointer 15 V.110 14 0 13 0 12 0 11 CSM Transmit Data Pointer Next Transmit Descriptor Pointer FE: Frame End; this bit is valid in all modes. It indicates that after sending the data in the transmit data section - the device generates an interrupt with FI bit set for HDLC, TMB, TMR, TMA ERR bit set for V.110/X.30 - the device then sends for HDLC, IFTF = 0 * (FNUM + 1) x 7EH * 7E, (FNUM - 1) x FFH, 7E for HDLC, IFTF = 1, FNUM 1 * 7E for HDLC, IFTF = 1, FNUM = 0 for TMB, TMR (FNUM 1) * (FNUM + 1) x 00H * 000H for TMR, FNUM = 0 * (FNUM + 1) x TFLAG for TMA, FA = 1 for TMA, FA = 0 * (FNUM +1) x FFH * three frames with synchronization errors for V.110/X.30 before starting with the data of the next transmit descriptor. If the data of the next transmit descriptor are not available in time (e.g. because the descriptor has FE and HOLD set) the device sends the interframe time-fill indefinitely. 10 9 8 7 6 5 FNUM 4 3 2 1 0 21 20 19 18 17 16
FE HOLD HI
User's Manual
162
01.2000
PEB 20320
Detailed Register Description HOLD: If the MUNICH32 detects a hold bit it - generates an interrupt with ERR bit set if FE = 0 or V.110/X.30 mode - sends the data in the current transmit data section - generates the FCS bits for HDLC and CS = 0 and CSM = 0 - the device then sends at least for HDLC, IFTF = 0 * (FNUM + 1) x 7EH for HDLC, IFTF = 1 * 7E, FNUM x FFH for TMB, TMR (FNUM 1) * (FNUM + 1) x 00H * 0000H for TMR, FNUM = 0 * (FNUM + 1) x TFLAG for TMA, FA = 1 for TMA, FA = 0 * (FNUM + 1) x FFH * three frames with synchronization errors for V.110/X.30. - It polls the HOLD bit and the next transmit descriptor address, but does no branch to a new descriptor until the HOLD bit is reset. The next transmit descriptor address is read but not interpreted as long as HOLD = 1. Therefore it can be changed together with setting HOLD = 0. The polling occurs at most every 8 valid clock cycles of the channel and corresponds with internal requests from TF to TB. - The device sends interframe time-fill until HOLD = 0 is polled. The HOLD condition is also discarded if a transmit jump, fast transmit abort or transmit initialization command is detected during the polling. The MUNICH32 then branches to the transmit descriptor determined by FTDA even though the HOLD bit of the current transmit descriptor may still be `1'. HI: NO: Host initiated Interrupt; if the HI bit is set, MUNICH32 generates an interrupt with set HI bit after transferring all data bytes. This byte number defines the number of bytes stored in the data section to be transmitted. A transmit descriptor and the corresponding data section must contain at least either one data byte or a frame end indication. Otherwise an interrupt with set ERR bit is generated. This bit indicates that in the corresponding data section the E-, S- and X-bits of the following V.110/X.30 frame are stored. MUNICH32 reads these bits and inserts them into the next possible V.110/X.30 frame. The data section may contain only two bytes specified in the next figure. The first transmit descriptor after a transmit initialization channel command must have this bit set if it revives the channel from a transmit off condition or after a pulse at the reset pin.
V.110:
User's Manual
163
01.2000
PEB 20320
Detailed Register Description Intel Mode 31 E7 15 0 30 E6 14 0 29 E5 13 0 28 E4 12 0 27 E3 11 0 26 E2 10 0 25 E1 9 0 24 SB 8 0 23 SA 7 0 22 X 6 0 21 0 5 0 20 0 4 0 19 0 3 0 18 0 2 0 17 0 1 0 16 0 0 0
Motorola Mode 31 0 15 SA CSM: 30 0 14 X 29 0 13 0 28 0 12 0 27 0 11 0 26 0 10 0 25 0 9 0 24 0 8 0 23 0 7 E7 22 0 6 E6 21 0 5 E5 20 0 4 E4 19 0 3 E3 18 0 2 E2 17 0 1 E1 16 0 0 SB
CRC Select per Message: This bit is only valid in HDLC mode with CS = 0 and only in conjunction with the FE bit set. If set, it means that no FCS is generated automatically for the frame finished in this transmit descriptor. FNUM denotes the number of interframe time-fill characters between 2 HDLC or TMB frames. For X.30/V.110 these bits have to be set to `0'. FNUM = 0 means that after the current frame only 1 character (7EH for HDLC and 00H for TMB, 000H for TMR, TFLAG, TFLAG for TMA, FA = 1; FFH for TMA, FA = 0) is sent before the following frame (shared flags). FNUM = 1 means that after the current frame 2 characters (7EH 7EH for HDLC and 00H 00H for TMB and TMR, TFLAG, TFLAG for TMA, FA = 1; FF FFH for TMA, FA = 0) are sent before the following frame (non shared flags). FNUM = 2 means that after the current frame 3 characters (7EH 7EH 7EH (IFTF = 0) or 7EH FFH 7EH (IFTF = 1) for HDLC and 00H 00H 00H for TMB and TMR, TFLAG, TFLAG, TFLAG for TMA, FA = 1; FF FF FFH for TMA, FA = 0) are sent.
FNUM:
User's Manual
164
01.2000
PEB 20320
Detailed Register Description FNUM = k means that after the current frame k + 1 characters are sent for ITFT = 0 and HDLC (k + 1) times 7EH 7EH, (k - 1) times FFH, 7EH for ITFT = 1 and HDLC for TMB, TMR (k + 1) times 00H (k + 1) times TFLAG for TMA, FA = 1 (k + 1) times FFH for TMA, FA = 0. For HDLC mode FNUM is reduced by one eight of the number of zero insertions if FA is set. If the reduction would result in a negative number of interframe time-fill characters it is set to 0. Transmit Data Pointer: This 32-bit pointer contains the start address of the transmit data section. Although MUNICH32 works only long word oriented, it is possible to begin a transmit data section at an uneven address. The two least significant bits (ADD) of the transmit data pointer determine the beginning of the data section and the number of data bytes in the first long word of the data section, respectively. ADD: 00 = 4 bytes 01 = 3 bytes 10 = 2 bytes 11 = 1 byte MUNICH32 reads the first long word and discards the unused least significant bytes. The NO establishes (determines) the end of the data section, whereas the remainder of I (NO ADD) / 4 I defines the number of bytes in the last long word of the data section. MUNICH32 reads the last long word and discards the unused most significant bytes of the last long word. If the first access is the same as the last access, ADD specifies the beginning of the data section and NO the number of data bytes in the long word. All unused bytes are discarded.
User's Manual
165
01.2000
PEB 20320
Detailed Register Description For example (Intel mode): 1) ADD = 01, NO = 8 11 10 01 - byte 3 byte 7 3 long words are read 00
byte 2 byte 1 byte 0 byte 6 byte 5 byte 4 - - -
2) ADD = 00, NO = 8 11 10 01 00 byte 0 byte 4 - 2 long words are read
byte 3 byte 2 byte 1 byte 7 byte 6 byte 5 - - -
3) ADD = 10, NO = 1 11 - - - - - 10 byte 0 - - - 01 - - - 1 long word is read! 00
For example (Motorola-mode): 1) ADD = 01, NO = 8 11 - byte 7 10 01 00 byte 2 byte 6 - 3 long words are read
byte 0 byte 1 - -
byte 3 byte 4 byte 5
2) ADD = 00, NO = 8 11 10 01 00 byte 3 byte 7 2 long words are read
byte 0 byte 1 byte 2 byte 4 byte 5 byte 6 3) ADD = 10, NO = 1 11 -
User's Manual
10 -
01 byte 0 -
00 1 long word is read!
01.2000
166
PEB 20320
Detailed Register Description Next Transmit Descriptor Pointer: This 32-bit pointer contains the start address of the next transmit descriptor. After sending the indicated number of data bytes, MUNICH32 branches to the next transmit descriptor to continue transmission. The transmit descriptor is read entirely at the beginning of transmission and stored in an on-chip memory. Therefore all information in the next descriptor must be valid when MUNICH32 branches to this descriptor when HOLD = 0. For HOLD = 1 the next transmit descriptor pointer is polled together with HOLD; the next transmit descriptor must be valid, when HOLD = 0 is polled. This pointer is not used if a transmit jump, fast transmit abort or transmit initialization channel command is detected while the MUNICH32 still reads data from the current transmit descriptor or polls the HOLD bit. In this case FTDA is used as a pointer for the next transmit descriptor to be branched to.
User's Manual
167
01.2000
PEB 20320
Detailed Register Description 4.4 31 0 FE Receive Descriptor 30 HOLD C 29 HI 0 28 27 26 25 24 23 22 NO BNO Receive Data Pointer Next Receive Descriptor Pointer 15 0 14 0 13 0 12 0 11 0 10 0 9 0 8 0 7 0 0 6 0 0 5 0 0 4 0 0 3 0 0 2 0 0 1 0 0 0 0 0 21 20 19 18 17 16
Status
Receive Data Pointer Next Receive Descriptor Pointer The receive descriptor contains 4 long words; the first, third and fourth have to be written by the CPU, the second is written by the MUNICH32 when it branches to the next receive descriptor or when it starts polling the HOLD bit. Note: The MUNICH32 branches to a next descriptor without writing the second long word if the receive initialization command is used during normal operation (see Chapter 4.2.4) HOLD: Setting the HOLD bit by the host prevents the device from branching to the next descriptor. The current data section is still filled. - Afterwards the second descriptor long word is written by the MUNICH32. For HDLC, TMB, TMR the FE and C-bit is set. If the frame could not completely be stored into the data section the RA bit is set in the status. An interrupt with set FI bit is generated, and in case the frame was aborted, the ERR bit is also set. For TMA, V.110/X.30 the C-bit and the RA bit is set and an interrupt with set ERR but with FI = 0 is generated. - Afterwards the device starts polling the HOLD bit, received data, and received events normally leading to interrupts (with RT = 1) are discarded until HOLD = 0 is polled. Each 1 ... 4 byte data word or interrupt event normally leading to an access now results in a poll cycle. Whenever HOLD = 1 is polled the next receive descriptor address is read but ignored. - When HOLD = 0 is polled * for HDLC, TMB, TMR the device continues to discard data until the end of a received frame or an event leading to an interrupt (with RT = 1) is
User's Manual
168
01.2000
PEB 20320
Detailed Register Description detected. Afterwards the next received frame is transferred into the next receive descriptor. Interrupts are also generated again. * For V.110/X.30, TMA the device puts the next data into the next receive descriptor. Interrupts are also generated again. The HOLD condition is also discarded upon detection of a receive jump, fast receive abort or receive initialization command. The MUNICH32 then branches to the receive descriptor determined by FRDA even though the HOLD bit in the current receive descriptor may still be `1'. HI: NO: Host initiated interrupt; if the HI bit is set, MUNICH32 generates an interrupt with set HI bit after receiving all data bytes. This byte number defines the size of the receive data section allocated by the host. Because MUNICH32 always writes long words the number of bytes (data section size) must be a multiple of 4 and greater or equal to 4. The maximum data section size is 8188 bytes. After reception of an HDLC frame with a data byte number not divisible by 4 MUNICH32 first transfers the greatest entire ([number of data bytes/4]) in long words. Then the remainder of the data bytes is transferred in another long word, where the non-significant bytes are filled with random values. They should not be interpreted. For example a HDLC frame with one data byte is received: Receive Descriptor 00000000.00001000.00000000.00000 11000000.00000001.Status.00000000 receive data pointer next receive descriptor pointer The data bytes are stored into the receive data section according to the Little Endian convention (Intel mode) or Big Endian convention (Motorola mode). FE: Frame End: The frame end bit is `1' only in HDLC, TMB, TMR mode and indicates that a receive frame has ended in this receive descriptor. For TMA, V.110/X.30 the bit is always `0'. FE = 0 in HDLC, TME, TMR mode means that frame continues in the next receive descriptor or that it filled the current receive data section exactly (BNO = NO). In this case the next receive descriptor will have FE = 1, C = 1, BNO = 0 and no data bytes are stored in the corresponding data section. C: This bit is set by MUNICH32 if * it completes filling the data section normally (BNO = NO) FE = 0, status = 00 * it was aborted by a fast receive abort channel command status = 02
169 01.2000
Receive Data Section XX.XX.XX.data
User's Manual
PEB 20320
Detailed Register Description * for HDLC, TMB, TMR if the end of a frame was stored in the receive data section FE = 1, status gives the receive status determined by RD (interrupt with set FI bit is generated) * for V.110/X.30 mode if the 3 contiguous frames with errors in the synchronization pattern are received FE = 0, status = 20 or status = 21 interrupt with set ERR bit * for V.110/X.30 mode if the data could not be transferred to the shared memory due to RB buffer inaccessibility FE = 0, status = 01 or status = 21 interrupt with set ERR bit. C indicates that the second long word of the receive descriptor was written by the MUNICH32. Afterwards the MUNICH32 writes the next receive descriptor address into CCS. Then it branches to this descriptor immediately. BNO: Status: MUNICH32 writes the number of data bytes it has stored in the current data section into BNO. The MUNICH32 writes the status information into the status byte whenever it sets the C-bit. If the status information is not 00 or 40 an interrupt with ERR bit set is generated. The status is then a means to locate or analyze the receive error. The following table gives a general overview over the different status bits in relation to the channel modes. 6 SF 5 LOSS 4 CRCO 3 NOB 2 LFD 1 RA 0 ROF
7 0
HDLC CS = 0 0 NI HDLC CS = 1 0 0 V.110/X.30 0 TMB 0 TMR 0 TMA 0 0 0 0 0
0 0 I 0 0 0
ILN ILN 0 0 0 0
IL IL 0 IL IL 0
I I 0 I I 0
I I IF IF IF IF
I I I I I 0
Where `0' means that in the corresponding mode the bit is always `0'. It should not be interpreted though to be upward compatible to future versions.
User's Manual 170 01.2000
PEB 20320
Detailed Register Description NI ILN IL I IF means the bit may be `1' or `0' but does not cause an interrupt with set ERR bit. means that it may be `1' or `0' but should not be evaluated if LFD or NOB is also `1'. means that it may be `1' or `0' but should not be evaluated if LFD = 1. means that it may `1' or `0'. means that it may be `1' only after a fast receive abort channel command or detection of a HOLD bit in the current receive descriptor.
I, IF, IL, ILN lead to an interrupt with ERR bit set. Note: For HDLC, TMB, TMR the status word is only valid if the FE bit is set. The meaning of the individual status bits is as follows: SF = 1 (HDLC mode with CS = 0 only): The device has received a frame with 32 bit between start flag and end flag or end abort flag for CRC16 48 bit between start flag and end flag or end abort flag for CRC32 i.e. BNO was 1 or 2. Three contiguous frames with errors in the synchronization pattern were detected. A frame with a CRC error was detected CRCO = 0 means the frame had no CRC error. A frame whose bit content was not divisible by 8 was detected. NOB = 0 means that the frame content was divisible by 8. Long frame detected. If this bit is set a frame whose bit content was > MFL was detected and aborted. The reception will be continued as soon as a flag is recognized. Receive Abort; this bit indicates that for HDLC: the frame was ended by an abort flag (7FH) or by a receive abort command or a fast receive channel command or by a HOLD bit in the current receive descriptor. for V.110/X.30, TMB, TMR, TMA that the frame or data were aborted by a fast receive abort channel command or a HOLD bit set in the current receive descriptor. An overflow of the internal buffer RB has occurred and lead to a loss of data.
LOSS = 1 CRCO = 1 NOB = 1 LFD = 1
RA = 1
ROF = 1
Note: If ROF without FO interrupt is generated for a channel * for HDLC, TMB, TMR only the last part of one frame has been lost. * For V.110/X.30 only data but no status information (change E-, S-, X-bits, Loss) has been lost.
User's Manual
171
01.2000
PEB 20320
Detailed Register Description Note: In case of multiple errors all relevant bits are set. In case of ROF = 1 only the error conditions of the frame within which the overflow occurred are reported. Later frames that are aborted do not change the status. Receive Data Pointer: Receive Descriptor Pointer: This 32-bit pointer contains the start address of the receive data section. This 32-bit pointer contains the start of the next receive descriptor. It is not used if a receive jump, fast receive abort or receive initialize command is detected while the MUNICH32 still writes data into the current receive descriptor or polls the HOLD bit. In this case FRDA is used as a pointer for the next receive descriptor to be branched to.
User's Manual
172
01.2000
PEB 20320
Application Notes 5 5.1 5.1.1 Application Notes Test Loops Test Loop Definitions for the MUNICH32
Two basic types of test loops are provided by the MUNICH32, internal and external. Each of these types is further subdivided into channelwise and complete test loops thus providing four possible test loops. 5.1.1.1 Internal Complete Test Loop The serial data output is physically routed to the serial data input. The TX data appears on the TDATA output pin and the RDATA input pin is ignored. TCLK and RCLK have to be identical; TSP and RSP have to be identical. The logical Transmit and Receive channels have to be programmed identically.
CD & RSP RCLK P Interface & Enable Int. Complete Loop RDATA
1
TSP TCLK
TDATA
ITS08198
Figure 81
User's Manual
173
01.2000
PEB 20320
Application Notes 5.1.1.2 Internal Channelwise Test Loop One (and only one) logical channel is mirrored from the serial data output to the serial data input. The other logical channels are not affected by this operation. The transmit and receive data rates for this single logical channel must be identical. Normal TCLK, RCLK, TSP and RSP design rules apply. This test loop provides channelwise testing capabilities during idle channel time slots, without interfering with normal data transmission/reception.
CD 1 RDATA
P Interface
Channel X only
&
Enable Int. Channelwise Loop for Channel X TDATA
ITS08199
Figure 82 5.1.1.3 External Complete Test Loop The serial data input is physically routed to the serial data output. Data is received on the RDATA pin and routed to the TDATA pin. The received data can be stored in shared memory for additional diagnostic purposes. TCLK and RCLK have to be identical; TSP and RSP have to be identical.
User's Manual
174
01.2000
PEB 20320
Application Notes
CD RDATA & Enable Ext. Complete Loop P Interface RSP RCLK
TSP TCLK & 1 TDATA
ITS08200
Figure 83 5.1.1.4 External Channelwise Test Loop One (and only one) logical channel is mirrored from the serial data input to the serial data output. The other logical channels are not affected by this operation. The receive and transmit data rates for this single logical channel must be identical. Normal TCLK, RCLK, TSP and RSP design rules apply. This test loop provides channelwise testing capabilities during idle channel time slots, without interfering with normal data reception/ transmission.
CD RDATA Channel X only P Interface & 1 TDATA
Enable Ext. Channelwise Loop for Channel X
ITS08201
Figure 84
User's Manual 175 01.2000
PEB 20320
Application Notes 5.1.2 Test Loop Activation
All of the test loops are closed (activated) and opened (deactivated) by setting/resetting the appropriate combination of bits in the Action Specification (Table 10). Any unlisted combination of LOC, LOOP and LOOPI is an invalid operation. Although the data sheet (Data Sheet 08.93) specifically states that loops must be left (opened) by issuing the reset pin to `1', there are exceptions to this rule. Generally, the test loops can be opened by software. There are several cases that must be examined and these will be discussed in the next section. When closing (activating) a test loop, the IN, ICO, IM, RES, and IA bits should equal `0' and PCM and MFL should be set to the appropriate values. Table 10 Test Loop Activation Test Loop Internal complete Internal channelwise External complete External channelwise No loop LOC 0 1 0 1 0 LOOP 0 0 1 1 0 LOOPI 1 1 0 0 0 ASP xxxxxx08H xxxxxx28H xxxxxx10H xxxxxx30H xxxxxx00H
The following recommended procedure for activating a test loop assumes that the MUNICH32 has been fully initialized and the user desires to activate a test loop on channel x: * Initialize Rc and Tx channel as appropriate for type of test loop. * Close (activate) the test loop. * Perform test functions (transmit/receive data, check for interrupts, errors, etc.) * Open (deactivate) the test loop. * Perform Rc and Tx off function. Note: While the test loop is activated, do not execute the transmit off command. It will not have the effect of resetting the transmit formatter. 5.1.3 Test Loop Deactivation and Switching
As mentioned previously, a test loop can be opened (deactivated) by software. To deactivate a test loop a new ASP should be issued with LOC, LOOP, and LOOPI = 0 and all other bits should be set to the previous values used during activation. Listed below are the possible test loop operations that can be activated with software and those requiring a hardware reset. Table 11 is provided as a graphical representation of this information.
User's Manual
176
01.2000
PEB 20320
Application Notes 5.1.3.1 Software Operations Close and open internal complete loop. Close and open internal channelwise loop. Close and open external complete loop. Close and open external channelwise loop. Change from internal complete loop to internal channelwise loop. Change from external complete loop to external channelwise loop. 5.1.3.2 Hardware Reset Operations Change between the internal complete loop and external complete loop. Change between the internal channelwise loop and external channelwise loop. Change between the internal channelwise loop and internal complete loop. Change between the external channelwise loop and external complete loop. Change between internal channelwise loop and external complete loop. Change between internal complete loop and external channelwise loop. Change between external channelwise loop and internal complete loop. Change between external complete loop and internal channelwise loop. Table 11 Allowed Operations Change to Internal Complete Loop Internal Complete Loop Internal Channelwise Loop X HDW Reset required Internal Channelwise Loop SFW X External Complete Loop HDW Reset required HDW Reset required X HDW Reset required External Channelwise Loop HDW Reset required HDW Reset required SFW X
External HDW Reset Complete Loop required External Channelwise Loop HDW Reset required
HDW Reset required HDW Reset required
User's Manual
177
01.2000
PEB 20320
Application Notes 5.1.4 Test Loop Examples
5.1.4.1 Internal Channelwise Test Loop
Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles. ASP: A104-8004 ;CEPT, MFL=260, IN, IA=1 IQS: ICQ 0000-001F TSA[0]: 00FF-00FF ;TS0 = CH0 TSA[1...31]: 0000-0000 (x31) CSP[0]: 00E9-0006 ;Tx/Rc init, poll Tx Desc, HDLC FRDA FTDA 0000-0002 ;ITBS = 2 long words CSP[1...31] 0000-0000 0000-0000 0000-0000 0000-0000 (x31) CRA[0...31] 0000-0000 (x32) CTA[0...31] 0000-0000 (x32) ICQ: FRDA: 0000-0000 (x512) 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 4020-0000 0000-0000 RcvDtaPtr 0000-0000 C000-0000 XmtDtaPtr NxtTDPtr 0020-0000 XmtDtaPtr NxtTDPtr C020-0000 XmtDtaPtr 0000-0000
+ + + + + +
32 byte data block
32 byte data block
32 byte data block ;HOLD = 1
;
32 byte data block HOLD, FE = 1 for dummy frame
FTDA:
+ + + +
abcdefghijklmnop qrstuvwxyz012345 ;FE, HOLD = 1 ABCDEFGHIJKLMNOP QRSTUVWXYZ987654
User's Manual
178
01.2000
PEB 20320
Application Notes
Generate AR Pulse and wait for INT signal (set up TS0 and CH0). Read interrupt queue: ICQ:
9000-8000 9000-1000
;Action Request Acknowledge ;V2.2 (V2.1 = 8800-8000) ;Polls HOLD bit of 1st Tx Desc.
Set ASP for Internal Channelwise Loop test ASP: A104-0028 Generate AR Pulse and wait for INT signal. Read interrupt queue: ICQ:
;CEPT, MFL=260, Int. Chnl loop
9000-8000 9000-1000 9000-082020
;Action Request Acknowledge ;Polls HOLD bit of 1st Tx Desc. ;Rc ITF state change
Clear HOLD bit in FTDA (allow frame to Tx over Internal Chnl. Loop). Read interrupt queue: ICQ:
9000-1000 9000-1020
;End of Tx frame, polling HOLD bit of Tx desc. ;Rc frame complete
Read receive descriptors: FRDA: 0020-0000 4020-0000 RcvDtaPtr + NxtRDPtr + 0020-0000 4020-0000 RcvDtaPtr + NxtRDPtr + 0020-0000 C000-0000 RcvDtaPtr
;C = 1, NO = BNO abcdefghijklmnop qrstuvwxyz012345
;C = 1, NO=BNO ABCDEFGHIJKLMNOP QRSTUVWXYZ987654
+ +
;FE, C = 1, BNO = 0 ;empty! (p. 139 User's Manual FE description)
NxtRDPtr 4020-0000 0000-0000 RcvDtaPtr 0000-0000
32 byte data block
User's Manual
179
01.2000
PEB 20320
Application Notes 5.1.4.2 External Channelwise Test Loop
Generate HW RESET, and hold off RSP/TSP for 1000 SCLK cycles. ASP: IQS: TSA[0]: TSA[1...31]: CSP[0]: A104-8004 ICQ 0000-001F 00FF-00FF 0000-0000 (x31) 00E9-0006 FRDA FTDA 0000-0002 0000-0000 0000-0000 0000-0000 (x32) 0000-0000 (x32) ;CEPT, MFL=260, IN, IA=1
;TS0 = CH0 ;Tx/Rc init, poll Tx desc., HDLC
CSP[1...31] CRA[0...31] CTA[0...31] ICQ: FRDA:
;ITBS = 2 long words 0000-0000 0000-0000 (x31)
0000-0000 (x512) 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 0020-0000 0000-0000 RcvDtaPtr NxtRDPtr 4020-0000 0000-0000 RcvDtaPtr 0000-0000 C000-0000 XmtDtaPtr NxtTDPtr
+ +
32 byte data block
+ +
32 byte data block
+ +
32 byte data block ;HOLD = 1
32 byte data block ;HOLD, FE = 1 for dummy frame
FTDA:
+ +
User's Manual
180
01.2000
PEB 20320
Application Notes
Generate AR Pulse and wait for INT signal (set up TS0 and CH0). Read interrupt queue: ICQ:
9000-8000 9000-1000 9000-1000
;Action Request Acknowledge ;V2.2 (V2.1 = 8800-8000) ;Polls HOLD bit of 1st Tx Desc. ;FI Frame indication for the 1st Tx Desc. ;Now M32 starts polling HOLD bit of 1st Desc.
Set ASP for External Channelwise test loop ASP: A104-0030 ;CEPT, MFL=260, Ext. Chnl loop Generate AR Pulse and wait for INT signal. Read interrupt queue: ICQ:
9000-8000 9000-0820 9000-1020
;Action Request Acknowledge ;Only if other station uses idle code 7E ;Received frame complete
Read receive descriptors: ;assumes 64 byte frame externally looped FRDA: 0020-0000 ;with proper HDLC framing 4020-0000 ;NO = BNO RcvDtaPtr abcdefghijklmnop + NxtRDPtr qrstuvwxyz012345 + 0020-0000 4020-0000 ;NO=BNO RcvDtaPtr ABCDEFGHIJKLMNOP + NxtRDPtr QRSTUVWXYZ987654 + 0020-0000 C000-0000 ;FE, C = 1, BNO = 0 RcvDtaPtr ;empty! + NxtRDPtr + 4020-0000 0000-0000 RcvDtaPtr 32 byte 0000-0000 data block
User's Manual
181
01.2000
PEB 20320
Application Notes 5.2 5.2.1 MUNICH32 in a LAN/WAN Router Introduction
Subject of this application note is an ISDN/LAN Router, a communication system that enables two LANs to communicate via the ISDN.
LAN
Router
ISDN
Router
LAN
ITS08283
Figure 85 ISDN/LAN Router The structure of the whole system is shown in Figure 85. The router itself is realized as a stand alone solution. It is connected to a standard PC for software download and maintenance control only. After the download the system works fully independent of the host PC. The hardware of the ISDN/LAN router consists of an application specific part and a processor system. The application specific hardware is mainly based on the SIEMENS Component MUNICH32 (Multi Channel Network Interface Controller for HDLC) and a standard LAN controller. Both devices are integrated in the same processor system. The software of the ISDN/LAN router is formed by integrating the MUNICH32 Device Driver Module (DDM) and the corresponding LAN controller Device Driver Module in a Device Driver System (DDS). The device driver modules build a platform to implement the routing strategy in a separate application module. The application specific hardware, the MUNICH32 Device Driver Module and the application module are the main aspects described in the following chapters. The structure of the processor system is briefly illustrated. The DDS service routines are explained as far as necessary to understand this special application. It is suggested that the reader has some knowledge about the MUNICH32 before reading this application note. Detailed information about the MUNICH32, its features and memory structures are given in the MUNICH32 PEB20320 Data Sheet.
User's Manual 182 01.2000
PEB 20320
Application Notes 5.2.2 Hardware
The processor system is based on a Motorola 68040 processor. It contains 512 KByte SRAM, a bus controller and peripherals like timer, EPROM and interrupt controller. The application specific hardware is integrated by using a Peripheral Connector and an Alternate Busmaster Connector. The Peripheral Connector allows the integration of external peripherals. The Alternate Busmaster Connector is used to connect external bus masters to the local bus. The system is provided with a RS232 serial interface to download executable software on the board.
ISDN Interface
LAN Interface RS232 Timer EPROM Interrupt Controller SRAM Alternate Busmaster Connector Bus Controller Peripheral Connector MC68040
Glue Logic
i82596 i82C501 EM 2
MUNICH32 ACFA PRACT ISDN Connector
LAN Connector
ITB08284
Figure 86 Hardware Block Diagram
User's Manual
183
01.2000
PEB 20320
Application Notes Application Specific Hardware The application specific hardware consists of an ISDN primary rate interface and an Ethernet interface. The MUNICH32 PEB 20320 in conjunction with the layer 1 SIEMENS components ACFA (Advanced CMOS Frame Aligner) PEB 2035 and PRACT (Primary Rate Access Clock Generator and Transceiver) PEB 22320 are used to build the primary rate interface. Incoming data from the ISDN is first processed from the PRACT. It translates the HDB3 coded line signals in dual rail signals. The PRACT also supplies ACFA and MUNICH32 with clock signals. Main task of the ACFA is the frame alignment. Besides, the ACFA translates the dual rail data in a single rail, unipolar bit stream which can be processed by the MUNICH32. The MUNICH32 handles up to 32 channels of a full duplex PCM highway. All time-slots may have data rates between 8 Kbit/s and 64 Kbit/s. The MUNICH32 supports besides other protocols the HDLC formatting/deformatting. If programmed for HDLC mode, the MUNICH32 performs HDLC specific functions like framing, CRC check/generation, flag stuffing and zero bit insertion/deletion autonomously. An on-chip 64-channel DMA controller allows the device to store/read data into/from the SRAM. The DMA controller manages long word or word transfers via a 32-bit processor interface. The P interface can be configured to be Motorola 68020 or intel 80386 compatible.
P Interface MUNICH32
PCM Highway ACFA
Dual Rail Unipolar Signals PRACT
Overvoltage Line IN Line OUT
ITS08285
Figure 87 ISDN Interface The Ethemet interface is built with a LAN controller, a Manchester encoder/decoder and a transceiver. The LAN controller supports all IEEE 802.3 standards. The Ethernet framing: preamble generation, source address generation, destination address checking, short-frame detection, automatic length field handling is performed. After LAN controller processing the transmit data is Manchester encoded and forwarded to the transmission line, while receive data is Manchester decoded before being processed by the LAN controller.
User's Manual
184
01.2000
PEB 20320
Application Notes System Architecture The system architecture is shown in Figure 88. The MUNICH32, the CPU and the LAN controller store data in the shared memory. The communication between CPU and alternate bus master is done via the shared memory. The CPU informs the alternate bus masters with help of control signals about changes in the shared memory and vice versa. The MUNICH32 input control signal is the Action Request pulse (ACTION REQUEST). It is generated by one CPU write cycle to a defined address and decoding the address lines. The MUNICH32 then responds by generating an interrupt pulse and writing the respective interrupt information in the SRAM.
Control Signals
Control Signals
MUNICH32
CPU
i82596
Local Bus
Shared Memory
ITS08286
Figure 88 System Architecture
User's Manual
185
01.2000
PEB 20320
Application Notes Bus Arbitration Since three devices are using the bus it is necessary to implement a bus arbitration. Each bus master requests bus mastership and awaits bus control given to it by the arbiter. The bus arbitration protocol is also Motorola specific. The intel specific signals of the LAN controller (i82596) are translated into Motorola specific signals. The bus arbitration is realized in two devices GAL16V8 (15 ns), both containing a Finite State Machine. Arbiter 1 gives bus mastership to the CPU whenever no other bus master requests bus mastership. If either the MUNICH32 or the LAN controller requests bus mastership the arbiter 2 gives a bus request to the arbiter 1. Arbiter 1 forces the CPU to release the bus and gives bus mastership to arbiter 2. Arbiter 2 then responds to MUNICH32 or LAN controller. In this solution the priority of the MUNICH32 is higher than that of the LAN controller. Consequently if both alternate bus masters request bus mastership at the same time, bus mastership will be given to the MUNICH32. The LAN controller has to wait until MUNICH32 has finished his accesses and arbiter 1 returns the bus to the CPU. It might happen, that some Ethernet frames get lost, because the LAN controller can not get access to the bus in time, but the loss of incoming data from the ISDN (where fees have to be paid) is minimized.
Arbiter 2
Arbiter 1
MUNICH32
CPU
i82596
ITS08287
Figure 89 Bus Arbitration
User's Manual
186
01.2000
PEB 20320
Application Notes Bus Timing Adaptation1) The bus controller manages memory accesses of all bus masters (CPU, MUNICH32 or LAN controller). The bus controller timing is Motorola 68040 specific. The MUNICH32 bus interface is either Intel specific or Motorola 68020/030 specific. Therefore the MUNICH32 bus timing needs to be adapted by using simple glue logic. One Gate Array Logic (Gal16V8, 15 ns) contains all necessary logic. The MUNICH32 Address Strobe (AS) signal determines valid addresses on the bus. The equivalent Motorola 68040 control signal is the Transfer Start (TS). During MUNICH32 write cycles valid data on the bus is indicated with the Data Strobe (DS) signal. MUNICH32 write and read bus cycles are terminated with the Data Transfer Acknowledge (DSACK) signal. For the Motorola 68040 the end of a bus cycle is indicated by the Transfer Acknowledge (TA) signal. During MUNICH32 bus cycles the MUNICH32 output signal AS is used to generate the bus controller input signal TS. The TS is deasserted with the MUNICH32 input DSACK rising edge. Since all bus cycles have the same length the DSACK signal is generated two bus clock cycles after AS is detected low. TS is tristated, if the MUNICH32 is not busmaster. This signal is driven by another bus master during that time.
BCLK
SCLK
TS
TA
Addr
Data
AS
DSACK
ITD08288
Figure 90 MUNICH32 Timing Adaption
1)
See also Chapter 5.2.6.
User's Manual
187
01.2000
PEB 20320
Application Notes The LAN controller's (i82596) bus timing also needs to be adapted. The address lines A1, AO, Size 0 and Size 1 need to be generated, because the LAN controller performs 8 bit and 16 bit cycles as well as 32 bit cycles. There are also some non standard bus signals for the LAN controller, that have to be generated. Furthermore the System Clock and the Bus Clock have to be synchronized. All necessary glue logic for the LAN controller is realized in four devices Gal 16V8. 5.2.3 Software
The software is based on a message oriented device driver system. The device driver modules and application modules have a structure that allows to access them via defined entry points. Module Entry Points Two Entry points offer access to the DDMs. Messages can be sent to the DDM via the Message Entry Point. A hardware interrupt causes the program to branch to the Interrupt Entry Point. The APM also offers access via a Message Entry Point, but since the APM does not control any hardware, there does not exist any Interrupt Entry Point.
Device Driver System
Message
Message
Device Driver Module Interrupt Hardware
Application Module
ITS08289
Figure 91 Module Entry Points
User's Manual
188
01.2000
PEB 20320
Application Notes DDS Tasks The message transfer between the modules is the main task of the DDS, realized by some service routines. DDMs and APMs are integrated in the DDS by executing a Module Init Routine. The Module Init Routine is called by the DDS. Additionally the DDS offers service routines for memory management. All service routines can be used by all modules. Some memory management functions will be presented in more detail. For detailed information about the other DDS service routines please refer to the SIPB 7520 Primary Rate User Board or EASY532 Datacom Userboard Documentation. Memory Management With the memory management functions the allocation of message descriptors, MUNICH32 receive/transmit descriptors1) or LAN controller receive/transmit descriptors is simplified. During initialization of the memory management module DDSM a pool of descriptors is prepared in a linked list. The memory management functions allow to allocate descriptors and to free descriptors. During initialization of the memory management module DDSM a pool of descriptors is prepared in a linked list. The memory management functions allow to allocate descriptors and to free descriptors. During allocation a descriptor is taken from the prepared list. After utilization the descriptor is given back to the descriptor pool. There is one pool for message descriptors and one pool for MUNICH32 receive/transmit and LAN controller receive/transmit descriptors. Because MUNICH32 transmit and receive descriptors differ and they both differ from the LAN controller transmit and receive descriptors, there are service functions available to convert the descriptor type.
1)
Refer to MUNICH32 Data Sheet.
User's Manual
189
01.2000
PEB 20320
Application Notes
Message Descriptor Pool Allocate Free
MUNICH32/LAN Controller Descriptor Pool Allocate
Convert
Free
ITS08290
Figure 92 Memory Management
User's Manual
190
01.2000
PEB 20320
Application Notes 5.2.3.1 Device Driver Module MUNICH32 Tasks The MUNICH32 Device Driver Module has to prepare all memory structures for the MUNICH32. The ACTION REQUEST Pulse has to be generated. The device driver module also has to treat the MUNICH32 interrupts. Message Entry Point Every incoming message results in executing a function. Function ResetMunich32 Action Action Specification Reset bit is set, All channels are initialized, all time-slots are initialized, ACTION REQUEST Pulse is generated. Sets PCM mode and maximum frame length, ACTION REQUEST Pulse is generated. Interrupt Attention bit is set, A new interrupt queue is defined, ACTION REQUEST Pulse is generated. Action Specification in-bit is set, Initializes receiver and transmitter of selected channel, ACTION REQUEST Pulse is generated. Initializes transmitter of selected channel, ACTION REQUEST Pulse is generated. Initializes receiver of selected channel, ACTION REQUEST Pulse is generated. Adds tx descriptors to the transmit descriptor queue and clears hoId bit of poll descriptor if the channel is active. If no poll descriptor is detected Initialize Channel Only bit is set, `transmit jump' command is given, if the previous command was not `receive abort' or `off the receive clear' command is given, ACTION REQUEST Pulse is generated. Initialize Channel Only bit is set, turns channel on or off, turn channel on: if last command was `transmit off' or `transmit abort' `transmit clear' is given and `transmit hold' bit is cleared, turn channel off: if channel is active and `transmit hold' bit is set, ACTION REQUEST Pulse is generated.
ConfigMunich32 InitlnterruptQueue InitChannel
InitTxChannel InitRcChannel SendFrame TxJump
TxHold
User's Manual
191
01.2000
PEB 20320
Application Notes Function TxShutDown Action Initialize Channel Only bit is set, gives `transmit off' command or `transmit abort' command, ACTION REQUEST Pulse is generated. Initialize Channel Only bit is set, If last command was `transmit off' or `transmit abort' `transmit clear' is given, `receive jump' command is given, ACTION REQUEST Pulse is generated. `Initialize Channel Only' bit is set, Gives receive off command if receiver was aborted otherwise gives receive abort command, ACTION REQUEST Pulse is generated. Sets/clears Internal Channelwise Loop, ACTION REQUEST Pulse is generated. Sets/clears Complete Loop, ACTION REQUEST Pulse is generated. ACTION REQUEST Pulse is generated.
RcJump
RcShutDown
SwitchlnternalChanLoop SwitchlnternalCompLoop ShowMunich32VersionNr
CheckActionRequestQueue Looks for messages to be processed and branches to the Message Entry Point. Interrupt Entry Point The information in the interrupt queue is read and a message containing that information is sent to the user. In case of a received frame the written receive descriptors are linked to a message and sent to the user. The next available descriptor in the list is linked to the memory structures. An equivalent number of new receive descriptors is allocated and linked to the end of the receive descriptor queue. In case of a transmit acknowledge interrupt the used transmit descriptors are released to the descriptor pool.
User's Manual
192
01.2000
PEB 20320
Application Notes Programming the MUNICH32 for this Application The basic programming of the MUNICH32 for this application is realized in the Module Initialization Routine. Further programming is done by calling the function `Init Channel' for each channel once. Transmit data is then added to the memory structures by passing a message with linked transmit descriptor(s) to the function `Send Frame'. Module Initialization Routine Here the IM-bit is cleared because the MUNICH32 DDM expects the action request acknowledge interrupt. The values for PCM and MFL are set. The PCM format is a 32channel format according to CEPT. The maximum frame length is set to its maximum. Finally the address and length of a new interrupt queue are defined. Those values will not be changed anymore. Init Channel Routine The function `Init Channel' initializes the time-slot assignment and the channel specification for one channel. The channel number is set to the value of the variable `channel'. The MUNICH32 is alerted to access all time-slot assignments and the channel specification by setting the in-bit. The fillmask (transmit and receive) for the selected channel is written in the appropriate word of the time-slot assignment. All other channels and their fillmasks are not affected. For this application all interrupts are enabled. Initialization of the selected channel comprises the definition of a new ITBS value and initialization of the receiver and the transmitter. The transmit hold bit is cleared. After initialization the MUNICH32 starts polling the hold bit of the current transmit descriptor. Therefore a transmit descriptor is allocated and connected to the memory structures. Its hold bit and fe-bit are set to one, its no-bits are set to zero. For that reason the MUNICH32 does not transmit anything but polls this descriptor. Since after the receiver's initialization the MUNICH32 is ready to receive data, a queue of receive descriptors is allocated and linked to the memory structures. The hold bit of the last descriptor in the list is set to indicate the end of the list. In all other descriptors the hold bit is cleared.
User's Manual
193
01.2000
PEB 20320
Application Notes Send Frame Routine Calling `SendFrame' after initialization of a channel results in executing `AddHdlcFrame'. In that routine the transmit descriptors are disconnected from the message and linked to the memory structures. If the message source is the `MROUTE Application Module' the hold bit and fe-bit indicating the end of a frame and the end of the list have already been set/cleared in the MROUTE module, they are not modified anymore. If the message source is any other module the fe-bit and hold bit are cleared in all descriptors except for the last one. There the hold bit has to be set, to prevent the MUNICH32 from branching to the next descriptor. Setting the fe-bit in the last descriptor only forces the MUNICH32 to send the data in one HDLC frame. The bits HI, V110 and CSM are cleared in both cases. Transmit/Receive Interrupt A transmit acknowledge interrupt is treated by returning the transmit descriptor(s) to the descriptor pool. After a receive interrupt (FI bit set) the receive descriptors with c-bit set, are disconnected from the list of receive descriptors, linked to a message and sent to the MROUTE module. The next free receive descriptor in the list is linked to the memory structures. An equivalent number of new descriptors is allocated and linked to the end of the receive descriptor list. 5.2.3.2 Application Module MROUTE The application module MROUTE implements the routing strategy. Routing Strategy Both devices the MUNICH32 and the LAN controller organize receive and transmit data in a linked list of receive descriptors and a linked list of transmit descriptors. The data is stored in data buffers of variable size. The receive/transmit descriptors contain the address of the data buffer. The basic idea behind the routing strategy is, to take the MUNlCH32's receive descriptor and link it to the LAN controller's transmit descriptor queue. On the other hand to take the LAN controller's receive descriptor and link it to the MUNlCH32's transmit descriptor queue.
User's Manual
194
01.2000
PEB 20320
Application Notes
ISDN 64 kbit/s each Channel fe = SET Frame Descr Count Count EOF = 0 Frame Descr Count Count EOF = 1 fe = SET
LAN max 10 Mbit/s
Ch1
0
2
EOF = SET fe = SET 0 Ch 2 Frame Descr Count Count EOF = 1 1 1 2
ITS08291
Figure 93 Insertion of additional Information To make efficient use of the available bandwidth, the parallel use of several B-channels is one of the routing strategy's goals. Every Ethernet frame is divided into several parts because the LAN controller stores the received data in several receive descriptors, if necessary. The frame is then sent via the ISDN by using a separate B-channel for every LAN receive descriptor. To ensure that the parts of the Ethernet frame will be reassembled in correct order, every part of the Ethernet frame is supplied with additional information. That additional information has to be extracted before reassembling the frame. In Figure 93 an example of one Ethernet frame consisting of three descriptors, spread over two B-channels, is shown. The additional information contains the frame number, the descriptor number and the information, whether the frame is completed. To simplify the extraction of the additional information every frame part and its additional information are sent in one HDLC frame.
User's Manual
195
01.2000
PEB 20320
Application Notes The fe-bit marks the end of one HDLC frame, the EOF bit marks the end of the Ethernet frame. The additional information comprises the 8-bit word descriptor count, 16-bit word frame count and EOF a 8-bit variable which indicates the last descriptor of the frame. Message Entry Point The message entry point calls two functions: IsdnRouteFrame and LanRouteFrame. An Ethernet frame is processed by IsdnRouteFrame, an ISDN frame by LanRouteFrame. The MUNICH32 receive descriptors are converted to LAN controller transmit descriptors and those of the LAN controller are converted to MUNICH32 transmit descriptors.
MROUTE Module LAN Route Frame ISDN Route Frame Message Descr Message Descr LAN Controller TX Descr MUNICH32 RC Descr
LAN Controller RC Descr MUNICH32 TX Descr MUNICH32 DDM LAN Controller DDM
ITS08292
Figure 94 Message Flow between DDMs and MROUTE Module Besides the IsdnRouteFrame realizes the insertion of additional information and splits an Ethernet frame on several B-channels. The additional information is stored in an extra allocated transmit descriptor which is placed before the descriptor containing the data. Every descriptor and the respective extra descriptor are connected to one message descriptor. This message with set hold bit and set fe-bit in the descriptor containing the data is further processed from the MUNICH32 DDM routine `Send Frame'. LanRouteFrame reassembles the Ethernet frames. It takes into account, that the parts might arrive with different delays. Every complete frame is connected to a message descriptor and than processed from the LAN controller DDM.
User's Manual 196 01.2000
PEB 20320
Application Notes 5.2.4 Performance Considerations
Some considerations about the performance are made by investigating the maximum data rate. Further investigations are made about the bus occupancy by all busmasters and the MUNICH32 poll access' influence on the data rate. Finally the processing of one frame is illustrated. Data Rates The data rate during transmission from the ISDN into the Ethernet was tested.
kbit/s 2000 1800 1600 1400 1200 1000 800 600 400 200 0 0 3 6 9 12 15 18 21
Data Rate available Data Rate without MUNICH32 polling Data Rate with MUNICH32 polling Channels 24 27 30
ITD08293
Figure 95 Data Rate The size of one data buffer is 128 Byte. If the number of channels exceeds 24 the data rate depends on the MUNICH32 transmitter. If the transmitter is initialized the data rate decreases. This shows the influence of the MUNICH32 polling the Hold bit.
User's Manual
197
01.2000
PEB 20320
Application Notes Bus Occupancy The bus occupancy during normal operation is shown in Figure 96. In this case the data buffer size was 32 Byte. The CPU has busmastership during 90% of the time. The MUNICH32 as well as the LAN controller, each have busmastership 5% of the time. The bus occupancy of the MUNICH32 is calculated to 2.5%1). In this system it is higher because of inserted wait states in every bus cycle. Another reason is the bus controller's clock which is switched from 33 MHz to 40 MHz. This and the existence of two alternate bus masters results in a more time consuming arbitration protocol than that needed for a simpler architecture.
i82596 M32 5 % 5%
CPU 90 %
ITD08294
Figure 96 Bus Occupancy
1)
Compare Data Sheet.
User's Manual
198
01.2000
PEB 20320
Application Notes MUNICH32 Polling The influence of the polling can be illustrated by showing the bus occupancy of MUNICH32 poll accesses only.
M32 17 %
Idle 10 %
CPU 73 %
ITD08295
Figure 97 Bus Occupancy During Polling Here the MUNICH32 is polling 31 channels (= 31 x 2 read accesses during 125 s). Every access is 5 clock cycles long, instead of the minimum length of 4 clock cycles. The time for the arbitration protocol needed during every access results in bus idle time.
User's Manual
199
01.2000
PEB 20320
Application Notes Frame Processing During normal operation the processing of a frame comprises three consecutive parts. During transmission from ISDN to LAN the frame is first processed from the MUNICH32, then from the CPU and finally from the LAN controller.
Frame 1
Frame 2
MUNICH32 CPU i82596 t
ITD08296
Figure 98 Frame Processing Though the CPU is never idle, its part on frame processing is that between the MUNICH32 and the LAN controller are active. The time to process one frame is the minimum delay required between frames during continuous transmission.
User's Manual
200
01.2000
PEB 20320
Application Notes 5.2.5 Final Remarks
This application note shows a design example for the MUNICH32 (PEB 20320). Though the design example is of reduced complexity it gives an idea of how to use the MUNICH32 in a system. The MUNICH32 is integrated in a 68040 processor system in conjunction with one more alternate bus master. To achieve higher data rates the time to process the frames should be minimized. This includes minimization of bus idle time. The bus arbitration still has big improvement potential because of its modular structure. Additionally the existence of the alternate bus masters results in clocking the bus controller with two different frequencies. This also results in increased idle time for the bus should therefore be modified. Furthermore frame processing could be shortened by eliminating the wait states in every bus cycle. The influence of MUNICH32 poll accesses is extremely high in this example, because of the bus arbitration architecture and the system architecture with one bus controller for all bus masters. But anyway it should always kept in mind, that the bus occupancy during polling is higher than during transmission. During transmission it decreases rapidly. No upper layer software is realized in this example so far. For `real life' routing layer 2 and 3 software module(s) have to be integrated.
User's Manual
201
01.2000
PEB 20320
Application Notes
MROUTE Module LAN Route Frame ISDN Route Frame
Upper Layer Software Message Descr
Upper Layer Software Message Descr LAN Controller TX Descr
MUNICH32 RC Descr
LAN Controller RC Descr MUNICH32 TX Descr MUNICH32 DDM LAN Controller DDM
ITS08297
Figure 99 Integration of Upper Layer Software
User's Manual
202
01.2000
PEB 20320
Application Notes 5.2.6 Adaption of the 68040 P Signals
begin header This GAL is used to adapt the 68040 -processor signals to the MUNICH32. It is used in a system with a frequency relationship of 1/2 PCLK/SCLK. end header begin definition
device input
gal1 6v8; bclk M32ASQ reset M32BGACKQ int ACREQM68 RWQ clk rclk DSACKQ TSQ RESETQ INTQ ACREQM32 sclk sb2 sb1 idle one two = 1, = 2, = 3, = 4, = 5, = 6, = 7, = 8, = 9; = 19; = 18, = 17, = 16, = 15, = 14; = 13, = 12; = 2, = 1, = 0;
{Select the device to be Gal16V8}
{= musclk}
feedback (com) output (com)
statebits
state_names
end definition
User's Manual
203
01.2000
PEB 20320
Application Notes begin equations TSQ.OE TSQ RESETQ INTQ ACREQM32 sclk end equations
= /M32BGACKQ; = /(/M32ASQ x DSACKQ); = /reset; = int; = /(/ACREQM68 x reset x /RWQ); = (/reset x rclk) + (reset x /clk);
begin state_diagram tktadaptor (sb2, sb1) state all: if (/reset + M32ASQ) then idle with DSACKQ = 1; endwith; state idle: DSACKQ = 1; if (/M32ASQ x reset) then one else idle; state one: DSACKQ = 1; go to two; state two: DSACKQ = 0; if M32ASQ then idle else two; end state_diagram
User's Manual
204
01.2000
PEB 20320
Application Notes 5.2.7 Schematics
LAN Interface SER_INT BRQ BGACKQ BGQ MUBRQ MUBGACKQ MUBGOQ MUBGQ SERINT.SCH LAN_CONT.SCH Ctrl A D
ISDN MUBGQ MUBGOQ MUBGACKQ MUBRQ BGQ BGACKQ BRQ Ctrl A D
EASY320.SCH
ITS08298
Figure 100
User's Manual 205 01.2000
PEB 20320
Application Notes
MUNICH32 PCLK3 RTCLK TRSP RDATA TDATA
ACFA_PRACT PCLK3 CLK2M FSCQ RDO XDI LIN1 FSQ LIN2 LOUT1 LOUT2 JP1 GND SYNC 3 2 1 1 14 2 15 3 16 4 17 5 18 6 19 7 20 8 21 9 22 10 23 11 24 12 25 13
P1
CLK4M CLK2M XCLK MUNICH32.SCH ACFAPRAC.SCH GND VCC
CONNECTOR DB25 Female
ITS08299
Figure 101
User's Manual 206 01.2000
PEB 20320
Application Notes
J1A 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 VG96 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 A31 A30 A29 A28 A27 A26 A25 A24 A23 A22 A21 A20 A19 A18 A17 A16 A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2
J1C 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 VG96 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 D31 D30 D29 D28 D27 D26 D25 D24 D23 D22 D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 100 96 94 91 102 107 109 114 116 120 122 126 128 133 135 139 143 147 149 154 156 160 2 6 8 13 15 19 21 26 28 33 35 39
U1 BE0 BE 1 BE 2 BE 3 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 RTCLK TRSP RDATA TDATA PCLK3
A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31
M32BGQ U8 OE CLK 12 13 14 15 16 17 18 19 O8 O7 O6 O5 O4 O3 O2 O1 8 7 6 5 4 3 2 1 11 BCLK 9 8 7 6 5 4 3 2 GND
RCLK RSP RDATA TCLK TSP TSP
44 45 46 69 68 67
M32BGQ
BGACKQ BRQ LOCKQ BBQ CRSTQ BGQ
BGACKQ BRQ
GAL16V8 RP1 1 2 3 4 5 6 7 8 4.7 k U7 OE CLK 12 13 14 15 16 17 18 19 O8 O7 O6 O5 O4 O3 O2 O1 8 7 6 5 4 3 2 1 11 9 8 7 6 5 4 3 2 16 15 14 13 12 11 10 9
VCC
J1B 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 VG96 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 MUSCLK BBQ BCLK TSQ BGQ LOCKQ M32BGQ BGACKQ WRQ PCSQ5 VCC
GND
JP 2 ADDWSQ 1 2
CRSTQ MUINTQ
D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 D18 D19 D20 D21 D22 D23 D24 D25 D26 D27 D28 D29 D30 D31
PCLK3
95 99 101 106 108 113 115 119 121 125 127 132 134 138 142 146 148 153 155 159 1 5 7 12 14 18 20 25 27 32 34 38 90 85 86 75 76 74 82 79 81 80 66 40
I/M D0 D1 CI 0 D2 CI 1 D3 CI 2 D4 CI 3 D5 CI 4 D6 D7 TEST D8 D9 D10 D11 D12 JTEST 0 D13 JTEST 1 D14 JTEST 2 D15 JTEST 3 D16 D17 RESET D18 SCLK D19 D20 D21 D22 D23 D24 D25 D26 D27 D28 D29 D30 D31 W,R/R,W ADS/AS DS READY/DSACK BERR B16 HOLD/BR HLDA/BG PM HLDAO/BGO AR INT/INT MUNICH32
73 47 48 49 50 51 65 GND 53 54 55 56 60 61 DSACKQ
MUBGACKQ
GND
MUSCLK
RWQ PCSQ5 INT MUBGACKQ CRSTQ ASQ TSQ MUINTQ
GAL16V8
VCC
R1 3.3 k MUBRQ
MUBGOQ MUBGQ
VCC GND
C1 100 nF
C2 100 nF
C3 100 nF
C4 100 nF
C5 100 nF
C6 100 nF
C7 100 nF
C8 100 nF
C9 100 nF
C 10 100 nF
C 11 100 nF
C 12 100 nF
C 13 100 nF
C 14 100 nF
ITS08300
Figure 102
User's Manual 207 01.2000
PEB 20320
Application Notes
J2A VG96
ADR3 ADR2 ADR1 ADR0
U10 LOOP RSTQ RDO AD0 AD1 AD2 AD4 AD5 XDI 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 PCSQ2 G0 G1 G2 G4 G5 GXDI G6 VCC D1 LED Red R2 1k 2 U2A 74HC04 1 VCC R3 4.7 k 11 JP 3 GXDI COS VCC R4 10 k AD0 AD 1 AD 2 AD 3 AD 4 AD 5 AD 6 AD 7 U3 PCSQ2 46 CE FRDQ 22 RD FRDQ 25 WR INTQ2 5 AINT 36 ACKNL ADR0 18 A0 ADR1 19 A1 ADR2 20 A2 ADR3 21 A3 27 COS RDO 4 RDO 34 XDI 33 8 39 40 6 37 9 10 11 12 13 14 15 16 ROID XOID RSIGM XSIGM RCHPY XCHPY D0 D1 D2 D3 D4 D5 D6 D7 ACFA 3 R5 1 M C15 47 nF GND VCC 74HC04 D3 LED Green GND 1 CLK 11 OE GAL16V8 CLK2MQ XCLK CLK4MQ CLK2M FSC GND 22 33 XTOM XTOP XDOM XDOP RDIM RDIP XRCLK RRCLK SCLK 3 44 43 42 31 30 41 29 28
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
7 30 31 37 36 38 39 40 4
RFSP 7 SYP 32 RES 35 2 1 D2 1N4148 JP4 U2B 4 R6 1k 3
32 28 29
ITS08301
Figure 103
User's Manual 208 01.2000
PEB 20320
Application Notes
J2C VG96
J2B VG96
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
PCSQ4 PCSQ3 PCSQ2
INTQ2
GND
VCC
U9 PCSQ2 G0 G1 G2 G4 G5 GXDI G6 RSTQ PCSQ3 WRQ AD 0 AD 1 AD 2 AD 3 AD 4 PCLK3 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 MODE JATT COS LP
R15 2.2 k LOOP VCC XDI RDO SYNC CLK2M CLK2MQ CLK4MQ FSC FSCQ XCLK CLK33_CON
1 CLK 11 OE GAL16V8 C24 47 nF C25 47 F VCC PCLK3 GND
CLK2MQ XCLK CLK4MQ CLK2M FSC FSCQ U4 6 7 30 31 37 36 38 39 40 4 5 16 15 32 28 29 FSC FSC XDIN XDIP RDON RDOP RCLK CLK2M CLK2M CLK4M CLK4M CLK12M CLK16M XCLK XTIN XTIP
GND
VSSD VSSR VSSX VSSX VDDD VDDR VDDX VDDX VDD2
35 41 23 22 34 42 19 18 1
GND D4 D5
VCC R7 15 k 8 R9 1k F6 SO5K130 R14 1k 2 1 LOUT2 F2 A81_C90X 2 GND D9 3 U6 1 LOUT1 1 F1 A81_C90X
3
U5 1
PRACT
XL 1 XL 2 RL 1 RL 2
20 24 44 2
5 R8 D6 VCC GND D7 GND VCC 15 k 6 10 ZKB_402/512
CS XTAL 4 XTAL 3 XTAL 2 XTAL 1
JATT SYNC MODE LL LR LS 2 LS 1 LS 0
D8 C26
R12 1k LIN1 1 F3 A81_C90X 2 1 LIN2 F4 A81_C90X 2
33 9 10 12 13
43 17 27 3 26 14 11 8
X2 16 MHz C16 C17 12 pF C18 12 pF C19 VCC
VCC R 2.2 k
GND
100 nF
R11 60 k R11 60 k
8 5 6 10 ZKB_402/512
F5 SO5K130 R13 1k
D10 X1 12 MHz C20 C21 10 pF C22 10 pF GND VCC GND
D11
GND C28 100 nF C29 100 nF C30 100 nF C31 100 nF
ITS08302
JATT SYNC MODE G4 G5 G2 G1 G0
G6
C23
VCC GND
Figure 104
User's Manual
209
01.2000
FRDQ
RSTQ
WRQ
AD7 AD6 AD5 AD 4 AD 3 AD2 AD 1 AD 0
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
PEB 20320
Application Notes
Data
U 14 15 16 17 18 19 20 21 25 26 27 28 29 30 31 32 35 36 37 38 39 40 41 42 43 46 47 48 50 51 52 53 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D 10 D 11 D 12 D 13 D 14 D 15 D 16 D 17 D 18 D 19 D 20 D 21 D 22 D 23 D 24 D 25 D 26 D 27 D 28 D 29 D 30 D 31 BE 0 BE 1 BE 2 BE 3 A2 A3 A4 A5 A6 A7 A8 A9 A 10 A 11 A 12 A 13 A 14 A 15 A 16 A 17 A 18 A 19 A 20 A 21 A 22 A 23 A 24 A 25 A 26 A 27 A 28 A 29 A 30 A 31 W/R LOCK BREQ 114 113 112 109 108 107 106 105 104 103 102 101 97 96 95 94 93 92 91 90 87 85 84 83 82 81 80 79 76 74 73 72 71 70 120 126 115
BE
U CLK33 TSP_OUT PCLK3 TCLK_OUT CLK33_CON 18 16 14 12 9 7 5 3 1 Y1 1 Y2 1 Y3 1 Y4 2 Y1 2 Y2 2 Y3 2 Y4 1A 1 1A 2 1A 3 1A 4 2 A1 2A 2 2A 3 2A 4 2 4 6 8 11 13 15 17
33 MHz 8 PHI OSZI
ADDR
TSP_IN
1G 1 2G 19 74HCT244 GND
TCLK_IN
ADSQ VCC VCC RDTQ HOLD RLDA L_RESET VCC MUINTQ PORTQ CA VCC 16 15 14 13 12 11 10 9 4.7 k RP1 1 2 3 4 5 6 7 8 RDTQ MU_BGOQ L_LOCKQ CPURSTQ LAN_W_RQ ADSQ GND 16 15 14 13 12 11 10 9 2.7 k RP2 1 2 3 4 5 6 7 8 2.7 k 3.3 k GND
124 ADS 65 129 130 9 123 118 69 LE/BE BS 16 RDY CLK2 HOLD HLDA RESET
LAN_W_RQ L_LOCKQ GND R VCC
LPBK 58 CDT CRS RXD RXC TXD TXC RTS CTS 61 63 60 59 54 64 57 62 GND
Resistor
125 INT/INT 3 PORT 119 CA 82596DX
SER_INT
4.7 k
HOLD
1 GND
9 8 7 6 5 4 3 2
ITS08303
RAPACK
Figure 105
User's Manual 210 01.2000
PEB 20320
Application Notes
RESET MUCLK 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 L_RESET
Address BE PCSQ5 BEQ0 BEQ1 BEQ2 BEQ3 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 A1 A0 SIZ1 LAN_CSQ M32_CSQ
CPURSTQ
1 CLK 11 OE GND GAL16V8A Port GND MUCLK DTOEQ LAN_CSQ R_WQ M32_ARQ CPURSTQ CLK33 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12
ML_BGQ MU_BGACKQ A4 PORTQ CA
SIZ0
1 CLK 11 OE GND GAL16V8A
M32_ARQ Arbiter 2 MU_BRQ HOLD ML_BGQ MU_BGACKQ 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 O1 O2 O3 O4 O5 O6 O7 O8 19 18 17 16 15 14 13 12 BRQ BGACKQ HLDAIN MU_BGQ
1 CLK 11 OE GND GAL16V8A Signal
ADSQ LAN_W_RQ TAQ
HLDAIN
2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8
O1 O2 O3 O4 O5 O6 O7 O8
19 18 17 16 15 14 13 12
MUCLK CPURSTQ RDYQ R_WQ TSQ CLK33
1 CLK 11 OE GND GAL16V8A
CLK33
1 CLK 11 OE GND GAL16V8A
ITS08310
Figure 106
User's Manual 211 01.2000
PEB 20320
Application Notes
Data J1C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 VG96 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D 10 D 11 D 12 D 13 D 14 D 15 D 16 D 17 D 18 D 19 D 20 D 21 D 22 D 23 D 24 D 25 D 26 D 27 D 28 D 29 D 30 D 31 VG96 J1B 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 PCLK3 DTOEQ TAQ MUINTQ0 CPURSTQ J1A 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 VG96 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A 10 A 11 A 12 A 13 A 14 A 15 A 16 A 17 A 18 A 19 A 20 A 21 A 22 A 23 A 24 A 25 A 26 A 27 A 28 A 29 A 30 A 31
Address
MUINTQ
GND VCC
PCSQ5 W_RQ BGACKQ ML_BGQ LOCKQ BGQ_68 TSQ BCLK BBQ
MUCLK
ITS08311
Figure 107
User's Manual 212 01.2000
PEB 20320
Application Notes
GND R 78 SERINT U TXD TXCQ RTSQ RXD RXCQ CRSQ CDTQ C CAP LPBKQ 17 TXD 16 TXC 15 TEN 9 8 6 7 1 RXD RXC CRS CDT ENETV1 CLSN CLSN RCV RCV TRMT TRMT 12 11 4 5 19 18 1 2 3 4 5 6 R 78 R 240 R 240 U CD+ CDRX+ RXTX+ TXCDS 20 RXI 18 TXO 17 HBE 16 GND R 1 M C 0.01 F
J BNC
2 NOOR 3 LPBK/WDTD 82C50TAD
X1 14 X2 13
Y EM2 C 30 pF 20 MHz C 30 pF GND
VEE 11 DM 12
1
2
3
GND
JP JUMPER3X1 VCC
UA 1 O4 10 VCC C k105 R 40 k 2 R 150 U CEXT
D LED Yellow
GND GND
11 REXT/CEXT 9 RIN 3 4 5 A1 A2 B T21 U 10 CEXT Q6 Q1 R 150 D GND LED Green
VCC
C k105 R 40 k
11 REXT/CEXT 9 RIN 3 4 5 A1 A2 B T21 Q6 Q1 R 150 D VCC LED Red
ITS08312
Figure 108
User's Manual 213 01.2000
PEB 20320
Application Notes 5.3 Memory Bus Occupancy for a Single MUNICH32
The MUNICH32 may be used in different system architectures depending mainly on how the data buffers are shared between the interacting bus masters. In the following the memory bus occupancy is calculated for a system, where the MUNICH32 is directly coupled with a 32-bit CPU (compatible to either Motorola 68020 or Intel 386) sharing one common local CPU bus and translated via an appropriate system bus controller sharing the system memory as well. This example system looks very similar to the one depicted in the Figure 7 and Figure 9 of Chapter 1. In this case it is easier to estimate the behavior of the complete system. In addition to that, the following assumptions are made about the communication parameters: - HDLC operating mode - the MUNICH is clocked with SCLK = 16 MHz - the bus arbitration time is estimated to be about 4 extra clock cycles (SCLK) for every 10 MUNICH32 memory accesses (typical is 10 to 16) - the data buffer size allocated in the data buffer pool is 32 bytes for transmit and receive descriptors - a full duplex connection with up to 32 x 64 Kbit/s channels and heavy traffic load (shared flags) - the data size per HDLC frame is defined to be without the shared flag and the two CRC bytes - when the data size exceeds 32 bytes, more than one descriptor is needed for a single frame - an interrupt information is generated for every descriptor. The MUNICH32 needs the following 32-bit memory accesses (read or write): Receive: read descriptor write current descriptor address write status write interrupt write data (size) 3 1 1 1 accesses size 1 1 1 2 1 3 1 4 2 5 : :
User's Manual
214
01.2000
PEB 20320
Application Notes Transmit: read descriptor write current descriptor address write interrupt read data (size) 3 1 1 accesses size 1 1 1 2 1 3 1 4 2 5 : :
The accumulated access time for a single MUNICH32 channel, depending on the actual frame size, is then related to the serial transfer time on a PCM system: (3 + size) x 125 s. The following two diagrams illustrate the overall results for two different ranges and their corresponding resolution. As you can see, for frame size greater than 32 bytes the time needed for MUNICH32 memory accesses drops below 5%. That means in a simple communication subsystem (e.g. Primary Access Board) the CPU performance is also reduced by 5% only and it is therefore not necessary to use a complex multiport memory approach to reach a significant overall performance gain.
Memory Bus Occuppancy 25 % 20 Ch=32 Ch=30 Ch= 1
15
10
5
0 1 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 Number of Data Bytes
ITD04696
Figure 109 Frame Size 1 to 512
User's Manual 215 01.2000
PEB 20320
Application Notes
Memory Bus Occuppancy 25 % 20 Ch=32 Ch=30 Ch= 1
15
10
5
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Number of Data Bytes
ITD04697
Figure 110 Frame Size 1 to 32
User's Manual
216
01.2000
PEB 20320
Application Notes 5.3.1 Bus Occupancy Calculations
As described in the previous section, the MUNICH32 in a steady state condition consumes approximately 5% of the system bus bandwidth. Based on the conditions previously described, a set of equations can be used to describe the MUNICH32 system bus behavior. Other MUNICH32 systems can be evaluated using these equations. The Bus occupancy is defined as the ratio of the time required for memory accesses for that data to the time used to send the data. The two equations are defines as follows: Time used for memory accesses: = Number of received bits plus transmitted bits multiplied by the time required to transfer this information to/from memory. = {([6 + (1 + m)] x rc) + (5 + (1 + m)] x tc)} x (1 + 1/ba) x NC x sclk 6 for receive descriptor access 5 for transmit descriptor access (1 + m) for data access where m is the largest integer smaller (n - 1)/4 (n is the number of transmitted data bytes). rc is the number of receive channels. tc is the number of transmit channels. (1 + 1/ba) is the bus arbitration time sclk is the system clock (61 ns for 16.384 MHz) NC is the number of memory clocks per bus operation (0ws = 4, 1WS = 5, etc.). Time used to send the data is the number of transmitted bits per time slot multiplied by the frame time: = ((4 + n) x 8/abtc) x 125 s 4 because shared flags are not used + 2 byte CRC n is the number of octets to transmit abtc = assigned bits to channel e.g. a channel with one time slot of 1 bit would require 8/1 = 8 time slots to transmit a single octet. From the previous example, the variables are assigned the following values: Variable n Value m rc 32 tc 32 (1 + 1/ba) sclk 1.1 61 ns NC 4 abtc 8
32 bytes 7
User's Manual
217
01.2000
PEB 20320
Application Notes Applying these values to the equations yields the following: Time used to access memory = {([6 + (1 + 7)] x 32) + ([5 + (1 + 7)] x 32)} x (1.1) x 4 x 61 ns = {(14 x 32) + (13 x 32)} x 1.1 x 244 ns = {864} x 268.4 ns = 231.9 s. Time used to send data = ((4 + 32) x 8/8) x 125 s. = 36 x 125 s. = 4500 s. Bus occupancy = 231.9 s/4500 s = 5.1% When the packet size is much larger (256 bytes or larger), the bus occupancy decreases to less than 4%. Conversely, sending very small frames (4 bytes), causes bus occupancy to increase to over 11%. This is primarily due to the increased descriptor processing per packet. 5.3.2 Bus Occupancy for Idle Tx Channels
The previous discussion shows bus occupancy to be very low, even when a MUNICH32 is processing 32 channels of receive and transmit data. There is another system consideration of bus occupancy that must be examined. When a MUNICH32 channel has no data required for transmit, the channel must be temporarily (or permanently) stopped. There are several methods that may be used to stop the transmission. 1. The first method involves executing a channel command with TH = 1 (reactivation of the channel requires a new channel command with TH = 0). This method places the transmit channel on hold and prevents any further accesses of the memory for this channel. 2. A second method is based on statistical knowledge of the frequency of transmitted frames. If frames are transmitted without shared flags and if the average number of interframe time fill characters can be determined, the MUNICH32 can be programmed to suppress poll sequences. By setting FNUM in the Tx descriptor to a value (n) greater than 0, the MUNICH32 will transmit n + 1 idle characters after the end of the current frame. During this period of interframe time fill, the MUNICH32 will not poll the Tx descriptor. As an example, if it is determined that 5 idle characters typically occur between frames, FNUM can be set to 4. At the end of the current frame, 5 idle characters will be transmitted (625 s. on a DS0 channel) before the next frame is transmitted and no polls of the Tx descriptor will occur during that time.
User's Manual
218
01.2000
PEB 20320
Application Notes 3. The final method is to set the HOLD bit in the Tx descriptor. When the HOLD bit in the Tx descriptor is set, the MUNICH32 checks the status of the this bit for each time slot assigned to this channel. In this way, if the bit has been cleared, the MUNICH32 will immediately resume transmission. Although this method is simpler (in concept) for the software design, it causes the MUNICH32 to consume higher than normal bus bandwidth. For this reason, this is the least desirable of the three methods. In the previous example discussed, if all 32 channels were holding on the Tx descriptors, bus occupancy might rise as high as 17%. The reason bus occupancy rises this dramatically is due to the bus access once per time slot rather than once every four time slots (typical).
User's Manual
219
01.2000
PEB 20320
Application Hints 6 6.1 Application Hints Frequency Adaption in an Intel 368 Common Bus System
If you use the i386 as host processor with the MUNICH32 in a common bus system you have to adapt the different frequencies of the devices. The MUNICH32 works e.g. with a fixed frequency of 16.384 MHz in CEPT 32 channel PCM highway format. The i386 works with frequencies from 16 up to more than 50 MHz. If you compare the timing diagrams you will see that a few glue logic is necessary to adapt the MUNICH32 to the i386 timing. A possible adaption of the different frequencies is described below. For an example we use an i386 with a frequency of 16.384 MHz. The MUNICH32 is configured in the CEPT 32 channel PCM highway format with a SCLK of 16.384 MHz. The SCLK signal is build by dividing the 32.768 MHz CLK2 signal of the i386. That means that both clocks are synchronous. This is not necessary in general but selected in our example. The bus controller generates e.g. one wait state for the memory access. The falling edge of the ADS signal marks the beginning of a bus cycle which is completed with the sampled READY signal. A general bus controller should not see a difference between the two bus masters, so we have to delay the falling edge of the MUNICH32 ADS signal to that moment as the i386 would generate its ADS to get the READY signal at the same time. In the picture below you can see the relationship and the adaption of both timings as specified in our example. A second picture shows the adaption in an i386 24.576 MHz system. Again the clocks are synchronous.
User's Manual
220
01.2000
PEB 20320
Application Hints
S1 SCLK
S2 MUNICH32 SCLK=16.384 MHz
ADS
READY
T1 CLK2
T1
T2
T2
T1 i386, 16.384 MHz =>CLK2=2xSCLK
CLK
ADS
READY Delay
ITD04556
Figure 111
User's Manual 221 01.2000
PEB 20320
Application Hints
S1 SCLK
S2 MUNICH32 SCLK=16.384 MHz
ADS
READY
T1 CLK2
T1
T1
T1
T2
T2
T1 i386, 24.576 MHz =>CLK2=3xSCLK
CLK
ADS
READY Delay
ITD04557
Figure 112
User's Manual 222 01.2000
PEB 20320
Application Hints 6.2 - - - - MUNICH32 Memory Space Requirement
Implementation independent: Start Address 4 byte Control & Configuration Section 908 byte Tx Descriptor Size 12 byte Rc Descriptor Size 16 byte
Implementation dependent: - Interrupt Queue Size 64 byte < Interrupt Queue Size < 16384 byte - Data Buffer Size Data Buffer Size - Allocation of Tx and Rc descriptors per channel In general the memory space requirement may be calculated the following way:
Start Address + Size of Control & Configuration Section + Interrupt Queue Size + number of channels x [number of Tx Descriptors x (Tx Descriptor Size + Data Buffer Size)] + number of channels x [number of Rc Descriptors x (Rc Descriptor Size + Data Buffer Size)] --------------------------------------------- = Total MUNICH32 Memory Space Requirement
Example: The MUNICH32 is used in a 31 channel ISDN Primary Access application, that means that 31 full duplex channels are active. The LAPD protocol is implemented. In this case a window size of 7 is specified, that means that 7 Rc Descriptors and in transmit direction 7 Tx Descriptors must be available for each channel. The Data Buffer Size is set to 260 byte according to the LAPD specification. Summary: - - - - 31 channels; Interrupt Queue Size = 1024 byte; 7 Tx and 7 Rc Descriptors; Data Buffer Size = 260 byte;
In our example a memory space of 120 kbytes is required.
User's Manual
223
01.2000
PEB 20320
Application Hints 6.3 Serial Interface to different PCM Systems
The serial interface of the MUNICH32 is very general and comprises standard clock, PCM frame synchronization and data signals, which are independent for both directions. The following description explains typical applications integrating the MUNICH32 into 2.048 Mbps PCM systems, like SIEMENS System Interface for Primary Access and the MITEL ST BUS. In these systems the receive and transmit clocks are identical. The general timing is shown in Figure 113 (see also Chapter 2.1).
RCLK=TCLK TSP TDATA RSP RDATA Time-Slot 0
ITD04694
Time-Slot 0
Figure 113 The RSP pulse is shifted by one clock period against the TSP pulse. The main task using this timing for different PCM systems is to adapt the TSP and RSP pulses appropriately, as described below. 6.3.1 MUNICH32 for SIEMENS Primary Access Interface
The SIEMENS devices for the Primary Access Interface is the Frame and Line Interface Component (FALC54). This device can directly be connected to the MUNICH32 without any additional glue logic. In combination with the MUNICH32 this application is the most effective way to build a powerful and flexible Primary Access Interface, especially supporting different combined B channel paths over long distances (LAN-WAN Internetworking). The following block diagram illustrates how easy it is to integrate the MUNICH32 into a Primary Access application based on SIEMENS devices.
User's Manual
224
01.2000
PEB 20320
Application Hints
TCLK TSP TDATA
SYPXQ XDI SCLKX
MUNICH32 PEB 20320
RDATA RSP RCLK SCLKR RDO SYPRQ
FALC54 PEB 2254
CLKX CLK8M FSCQ FSC
ITS07370
Figure 114 The adaption of the TSP and RSP pulses is solved by means of shifting the receive data and transmit data in the FALC54 device appropriately. In this case the TSP and RSP synchronization pulses are also identical. The FALC54 device contains special registers to control the bit shift of the serial bit streams at the system interface (see FALC54 Data Sheet). With the following register programming the bit shift selected is T = 509 for the MUNICH32 transmit data and T = - 1 for the receive data respectively. The programming is as follows: XDI: XC1.XTO = 3DH XC0.XCO = 06H => X = 494 => X = 5 => T = 509 => T = - 1
RDO: RC1.RTO = 00H RC0.RCO = 05H
User's Manual
225
01.2000
PEB 20320
Application Hints The timing in principle is depicted in the following diagram. Without all details of a typical electrical timing it illustrates how the different signals from MUNICH32, and FALC54 are mapped in such a Primary Access system.
FSC=TSP=RSP
CLKX=RCLK=TCLK
TDATA
=XDI (T=509)
RDATA
=RDO (T=-1)
ITD08282
= : Invalid area = : Channel 0, Bit 0 (Least Significant Bit)
Figure 115
User's Manual
226
01.2000
PEB 20320
Application Hints 6.3.2 MUNICH32 in Systems with MITEL ST BUS
A few more effort is necessary to integrate the MUNICH32 into a ST BUS system from MITEL. The basic assumption made here is that the clock master is the ST BUS system. That means all signals derived from the ST BUS need to be adapted to match the MUNICH32 timing requirements. First of all the clock signal C2 must be inverted before it can be used as the MUNICH32 clocks (TCLK = RCLK = C2). The next step is the generation of the TSP and RSP pulses out of the F0 signal, which is the ST BUS frame synchronization signal. The RSP pulse can be derived from the F0 signal by means of a simple D-Flip-Flop clocked with C2, as depicted in the following Figure 116. Due to the necessary phase relationship between the serial data streams and their corresponding TSP, RSP and F0 pulses, the effort to generate the TSP pulse is much higher than for RSP.
TCLK TSP TDATA MUNICH32 PEB 20320 RDATA RSP RCLK
STi ST-BUS STo C2 F0
Q & Q D
Decode '254' RES 8-Bit Counter
Q Q D
System Clock Adaption
ITS04692
Figure 116
User's Manual 227 01.2000
PEB 20320
Application Hints The TSP pulse must be derived from the F0 signal with a phase shift by 255 clock cycles to be at the right position. The corresponding timing is illustrated in the following diagram.
C2
F0
TSP
*)
RSP *)
RCLK=TCLK=C2
TDATA
=STi
RDATA
=STo
ITD04693
= : Invalid area = : Channel 0, Bit 0 (Least Significant Bit)
*)
Derived from F0 and synchronized by means of C2
Figure 117
User's Manual
228
01.2000
PEB 20320
Electrical Characteristics 7 Electrical Characteristics
Note: All specifications are for V3.4 unless otherwise specified. Version numbers are identified in the Interrupt Information bits VN(3:1): these bits are `0000' for version 1.1 `0001' for version 2.1 `0010' for version 2.2 `0100' for version 3.2 `0110' for version 3.4 7.1 Absolute Maximum Ratings Symbol min. Ambient temperature under bias: PEB PEF Storage temperature Voltage at any pin with respect to ground Limit Values max. 70 85 125 C C V 0 - 40 - 65 - 0.4 Unit
Table 12 Parameter
TA TA Tstg VS
VDD + 0.4
Note: Stresses above those listed here may cause permanent damage to the device. Exposure to absolute maximum rating conditions for extended periods may affect device reliability.
User's Manual
229
01.2000
PEB 20320
Electrical Characteristics 7.2 DC Characteristics
Table 13 TA = 0 to + 70 C; VDD = 5 V 5%, VSS = 0 V Parameter L-input voltage H-input voltage L-output voltage Symbol Limit Values min. max. 0.8 0.45 V V - - - 0.4 2.0 - Unit Test Condition
VIL VIH VQL
VDD + 0.4 V
IQL = 7 mA
(pin TDATA)
IQL = 2 mA
(all others) H-output voltage
VQH
VDD - 0.5 -
V
IQH = - 2 mA IQH = - 100 A
(all others) (pin HOLD/BR)
H-output voltage Power supply current operational power down (no clocks)
VQH ICC ICC ILI ILQ
2.4 - - - < 100 <2 10
V mA mA A
IQH = - 400 A VDD = 5 V
inputs at 0 V/VDD, no outputs loads 0 V < VIN < VDD to 0 V 0 V < VOUT < VDD to 0 V
Input leakage current Output leakage current
Note: The listed characteristics are ensured over the operating range of the integrated circuit. Typical characteristics specify mean values expected over the production spread. If not otherwise specified, typical characteristics apply at TA = 25 C and the given supply voltage.
User's Manual
230
01.2000
PEB 20320
Electrical Characteristics 7.3 Capacitances
Table 14 TA = 25 C; VDD = 5 V 5%, VSS = 0 V Parameter Input capacitance Output capacitance I/O-capacitance Symbol Limit Values min. max. 10 15 20 pF pF pF - - - 5 8 10 Unit Test Condition
CIN COUT CIO
7.4
AC Characteristics
TA = 0 to + 70 C; VDD = 5 V 5%
Inputs are driven to 2.4 V for a logical `1' and to 0.4 V for a logical `0'. Timing measurements are made at 2.0 V for a logical `1' and at 0.8 V for a logical `0'. The AC testing input/output waveforms are shown below.
2.4 2.0 Test Points 0.8 0.45 0.8 2.0 Device Under Test C Load = 150 pF
ITS00621
Figure 118 Input/Output Waveform for AC Tests
User's Manual
231
01.2000
PEB 20320
Electrical Characteristics 7.5 Microprocessor Interface Intel Bus Mode
S1 SCLK
1
S2
S1
A31-A2
2
BE(3:0),
ADS
3 3 4 5
READY
6 7
BERR
8
D31-D0 (write cycle) [DP(3:0)] D31-D0 (read cycle) [DP(3:0)] PCHK
9 10
11
11
ITD03510
Figure 119 Timing Diagram Intel Bus Mode
User's Manual
232
01.2000
PEB 20320
Electrical Characteristics
SCLK
12 12
HOLD
13 13
HLDAO
14 15
HLDA
16 17
Microprocessor Interface PCHK
High Z
High Z
11
ITD03511
Figure 120 Bus Arbitration Timing Diagram Intel Bus Mode Intel Bus Timing Table 15 No. 1 2 3 4 5 6 7 8 9 10 Parameter min. Address, valid delay BE, INT, W/R valid delay ADS valid delay READY setup time READY hold time BERR setup time BERR hold time Data valid delay (write) Data setup time (read) Data hold time (read)
233
Limit Values max. 20 20 20 - - - - 35 - - - - - 10 5 10 5 - 5 8
Unit ns ns ns ns ns ns ns ns ns ns
01.2000
User's Manual
PEB 20320
Electrical Characteristics Table 15 No. 11 12 13 14 15 16 17 Parameter min. Parity check valid delay HOLD valid delay HLDAO valid delay HLDA setup time HLDA hold time Microprocessor Interface (MI) driven after HLDA set MI tristated after bus accesses - - - 10 10 2 SCLK cycles - Limit Values max. 50 20 20 - - - 40 ns ns ns ns ns - ns Unit
User's Manual
234
01.2000
PEB 20320
Electrical Characteristics 7.6 Microprocessor Interface Motorola Bus Mode
T1 SCLK
18
T2
T3
T4
T1
A31-A2
INT, BE (3:0), R/W
26 20 29
AS DS
19 19 21 28 21
DSACK BERR
27 22 23
D31-D0 (read cycle)
24 25
ITD03513
D31-D0 (write cycle)
Figure 121 Timing Diagram Motorola Bus Mode
User's Manual
235
01.2000
PEB 20320
Electrical Characteristics
SCLK
30 30
BR
31 32
BG
33 33
BGACK Microprocessor Interface
34 35
BGO
36
SCLK BR BG
36 36
ITD03514
BGO
Figure 122 Bus Arbitration Timing Motorola Bus Mode Motorola Bus Timing Table 16 No. Parameter 18 19 20 21 22 23 Address, BE, INT, R/W valid delay AS, DS asserted after clock low AS, DS negated after clock low DSACK, BERR setup time to clock low Data read setup time to clock low Data read hold time to clock low
236
Limit Values min. - - - 5 5 8 max. 20 20 20 - - -
Unit ns ns ns ns ns ns
01.2000
User's Manual
PEB 20320
Electrical Characteristics Table 16 No. Parameter 24 25 26 27 28 29 30 31 32 33 34 35 36 Data write valid delay Data write hold from clock high Address valid to AS high Data valid to DS low DS high to data invalid AS high to address invalid BR valid delay BG setup time to clock high BG hold time after BGACK BGACK valid delay Microprocessor Interface driven after BGACK asserted Clock high to Microprocessor Interface tristated BGO valid delay from clock high
specified for V2.1 and V2.2. Not specified in Data Sheet 08.93.
Limit Values min. - - 10 10 5 10 - 5 10 - 1 SCLK cycle - - max. 35 35 - - - - 25 - - 25 - 40 40
Unit ns ns ns ns ns ns ns ns ns ns - ns ns
1) Newly
User's Manual
237
01.2000
PEB 20320
Electrical Characteristics Serial Interface Timing
37
39
RSP
43 42
RCLK
38 40 41
RDATA
44
46
TSP
50 49
TCLK
45 47 48
TDATA
ITD03515
Figure 123 Table 17 No. 37 38 39 40 41 Parameter Receive strobe guard time Receive strobe setup Receive strobe hold Receive data setup Receive data hold
238
Limit Values min. 10 5 5 5 5 max. - - - - -
Unit ns ns ns ns ns
01.2000
User's Manual
PEB 20320
Electrical Characteristics Table 17 (cont'd) No. 42 43 44 45 46 47 48 49 50 Parameter Receive clock high width Receive clock low width Transmit strobe guard time Transmit strobe setup Transmit strobe hold Transmit data delay Transmit clock to high impedance Transmit clock high width Transmit clock low width 60 60 20 5 5 - - 60 60 Limit Values min. max. - - - - - 40 50 - - ns ns ns ns ns ns ns ns ns Unit
Note: 1. The frequency on the serial line must be smaller or equal to 1 th /8 of the frequency on the P bus for 1.536 MHz, 1.544 MHz, 2.048 MHz 1/ th of the frequency on the P bus for 4.096 MHz. 4 2. For complete internal or complete external loop t42 and t49 must be greater or equal to 3 times t51. Clock Input Timing
51 52 53
SCLK
ITD03516
Figure 124 Clock Timing
User's Manual
239
01.2000
PEB 20320
Electrical Characteristics Table 18 No. 51 52 53 Parameter min. Cycle period Clock low time Clock high time 50 25 25 Limit Values max - - - ns ns ns Unit
Note: If fT is the frequency of the clock TCLK, fR the frequency of the clock RCLK and fS the frequency of the clock SCLK the equations 7.996 x max (fT, fR) fS 16.667 MHZ for CEPT, T1, E1 PCM mode and 3.998 x max (fT, fR) fS 16.667 MHZ for 4.096 MHz PCM mode describe the allowed range of frequencies for fS. System Interface Timing
AR
56
RESET
57 55
first action request AR after reset
ITT10668
Figure 125 Table 19 No. 55 56 57 Parameter min. Reset to first action request delay 12 SCLK cycles AR# pulse width Reset pulse width 2 SCLK cycles 2 SCLK cycles Limit Values max. - 5 SCLK cycles - - - - Unit
After power up a logical `1' at the reset pin of the MUNICH V3.4 sets the device into a reset state where the complete microprocessor bus interface is tristated and the internal reset sequence is started.
User's Manual
240
01.2000
PEB 20320
Electrical Characteristics The trailing edge of the reset starts the last part of the internal reset sequence and takes about 12 SCLK cycles. It is not allowed to give an action request (AR) during these first 12 SCLK cycles after the trailing edge of signal RESET. JTAG-Boundary Scan Timing
58 59 60
JTEST0 (TCK)
61 62
JTEST1 (TMS)
63 64
JTEST2 (TDI)
65
JTEST3 (TDO)
ITD03512
Figure 126 JTAG-Boundary Scan Timing Table 20 Intel Bus Timing No. Parameter min. 58 59 60 61 62 63 64 65 JTEST0 (TCK) period JTEST0 (TCK) high time JTEST0 (TCK) low time JTEST1 (TMS) setup time JTEST1 (TMS) hold time JTEST2 (TDI) setup time JTEST2 (TDI) hold time JTEST3 (TDO) valid delay 166 80 80 15 10 15 15 30 Limit Values max. inf - - - - - - - - - - - - - - - Unit
User's Manual
241
01.2000
PEB 20320
Package Outlines 8 Package Outlines P-MQFP-160-1 (Plastic Metric Quad Flat Package)
Sorts of Packing Package outlines for tubes, trays etc. are contained in our Data Book "Package Information". SMD = Surface Mounted Device User's Manual 242
Dimensions in mm
01.2000
GPM05247
PEB 20320
Appendix 9 9.1 Appendix Source Code Extract MUNICH32
The MUNICH32 code extract is taken from the low level device driver for the MUNICH32, which is written in `C'. This extract gives you a brief impression how a MUNICH32 device driver could be programmed. The munich control configuration (munichCtrlCfg) is a structure which consists of the following substructures: Action Specification Interrupt Queue Specification Time-Slot Assignment Channel Specification Munich Receive Descriptor Pointer Munich Transmit Descriptor Pointer actionSpec intQueueSpec timeSlot[ ] channelSpec[ ] currRcDescrAddr[ ] currTxDescrAddr[ ]
These substructures mainly consist of bit fields. The use of bit fields does not produce a speed optimized but a highly readable code, in our case to demonstrate the programming of the MUNICH32 very clearly. The structures are directly memory mapped to the MUNICH32 structures and listed below. In this short example we select the CEPT-32 PCM highway format and the HDLC mode. All time-slots are assigned to channel number 0. HDLC frames are send via channel0. There are two functions: InitChannel0AndSendFirstFrame() TxHdlcFrame().
The function InitChannel0AndSendFirstFrame() comprises the following initialization tasks: - - - - - - the MUNICH32 is configured for the CEPT32 channel format the interrupt queue is initialized and assigned each time-slot consists of 8 bit and all time-slots are assigned to channel 0 the transmit outputs and the receive inputs are active here nine transmit buffers are assigned to channel0 idle code flags.
User's Manual
243
01.2000
PEB 20320
Appendix The second part of the function prepares the device to send the first HDLC frame: - the linked list of frames to be send is registered - in receive direction a linked list of 10 receive descriptors with 32 bytes data each is prepared and installed. - the macro MUNICH32_ACTION_REQUEST() `generates' an activation request pulse to the MUNICH32 - the device reads the initialization data and transmits the first transmit frame The MUNICH32 then polls the hold bit of last transmit descriptor until this bit is cleared. If the hold bit is cleared the device sends the next data until it finds the next hold bit. The function TxHdlcFrame connects the transmit descriptor of the next frame with the last transmit descriptor of the last send frame and clears the hold bit; the next frame is send.
User's Manual
244
01.2000
PEB 20320
Appendix 9.2 ...
/*-------------------------------------------------------------------------- MUNICH32 Transmit Descriptor Structure -------------------------------------------------------------------------*/
Source Code
typedef struct munichTxDescr { unsigned fnum : unsigned csm : unsigned : unsigned v110 : unsigned no : unsigned hi : unsigned hold : unsigned fe : WORD8 _ptr data; struct munichTxDescr _ptr next; } MUNICH_TRANSMIT_DESCRIPTOR;
11; 1; 3; 1; 13; 1; 1; 1;
typedef MUNICH_TRANSMIT_DESCRIPTOR _ptr MUNICH_TX_DESCR_PTR
/*-------------------------------------------------------------------------- MUNICH32 Receive Descriptor Structure -------------------------------------------------------------------------*/
typedef struct munichRcDescr { unsigned unsigned no unsigned hi unsigned hold unsigned unsigned unsigned status unsigned bno unsigned unsigned c unsigned fe WORD8 _ptr data; struct munichRcDescr _ptr next; } MUNICH_RECEIVE_DESCRIPTOR;
: : : : : : : : : : :
16; 13; 1; 1; 1; 8; 8; 13; 1; 1; 1;
User's Manual
245
01.2000
PEB 20320
Appendix
typedef MUNICH_RECEIVE_DESCRIPTOR _ptr MUNICH_RC_DESCR_PTR;
/*-------------------------------------------------------------------------- MUNICH32 Structures -------------------------------------------------------------------------*/
typedef struct { unsigned channelNumber unsigned rt unsigned unsigned fo unsigned err unsigned sf unsigned ifc unsigned fi unsigned hi unsigned arf unsigned arack unsigned x unsigned sa unsigned sb unsigned e1 unsigned e2 unsigned e3 unsigned e4 unsigned e5 unsigned e6 unsigned e7 unsigned frc unsigned unsigned intFlag } MUNICH32_INTERRUPT_QUEUE; typedef struct { MUNICH32_INTERRUPT_QUEUE _ptr unsigned unsigned } INTERRUPT_QUEUE_SPECIFICATION; typedef struct { unsigned rcFillMask : 8; unsigned rcChannelNumber : 5;
: : : : : : : : : : : : : : : : : : : : : : : :
5; 1; 2; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 1; 4; 1;
addr; n : 8; : 24;
User's Manual
246
01.2000
PEB 20320
Appendix
unsigned unsigned unsigned unsigned unsigned unsigned rti : : txFillMask : txChannelNumber : tti : : 1; 2; 8; 5; 1; 2;
} TIME_SLOT_ASSIGNMENT; typedef struct { unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned unsigned MUNICH_RC_DESCR_PTR MUNICH_TX_DESCR_PTR unsigned unsigned } CHANNEL_SPECIFICATION; typedef struct { WORD32 } CURRENT_RC_DESCR_ADDR; typedef struct { WORD32 } CURRENT_TX_DESCR_ADDR;
iftf mode fa trv crc inv tflagCs tflag ra ro th ta to ti ri nitbs intMask frda; ftda; itbs
: : : : : : : : : : : : : : : : :
1; 2; 1; 2; 1; 1; 1; 7; 1; 1; 1; 1; 1; 1; 1; 1; 8;
: 6; : 26;
*currentReceiveDescriptorAddrCh;
*currentTransmitDescriptorAddrCh;
User's Manual
247
01.2000
PEB 20320
Appendix
typedef struct { unsigned unsigned ia unsigned loopi unsigned loop unsigned loc unsigned res unsigned im unsigned channelNumber unsigned unsigned ico unsigned in unsigned mfl unsigned pcm } ACTION_SPECIFICATION;
: : : : : : : : : : : : :
2; 1; 1; 1; 1; 1; 1; 5; 1; 1; 1; 13; 3;
/*-------------------------------------------------------------------------- MUNICH32 Control Block -------------------------------------------------------------------------*/
typedef struct { ACTION_SPECIFICATION INTERRUPT_QUEUE_SPECIFICATION TIME_SLOT_ASSIGNMENT CHANNEL_SPECIFICATION MUNICH_RC_DESCR_PTR MUNICH_TX_DESCR_PTR } MUNICH32_CTRL_CFG_SECTION; .. ..
actionSpec; intQueueSpec; timeSlot channelSpec currRcDescrAddr currTxDescrAddr
32; 32; 32; 32;
User's Manual
248
01.2000
PEB 20320
Appendix
/*-------------------------------------------------------------------------- Function : InitChannel0AndSendFirstFrame -------------------------------------------------------------------------- Description : Initialization of channel 0. - PCM Highway format CEPT 32-channel - HDLC Mode - All timeslots are assigned to channel 0. - Send the first HDLC frame -------------------------------------------------------------------------*/ static void InitChannel0AndSendFirstFrame ( MUNICH_TX_DESCR_PTR m32TxDescr ) { .. .. /* ------------------------------------------------------------------------*/ txDescr = m32TxDescr /* store transmit descriptor pointer */
/*=== Action Specification ==============================================*/ munichCtrlCfg.actionSpec.in = 1; /* initialization procedure munichCtrlCfg.actionSpec.ico = 0; /* initialize channel only munichCtrlCfg.actionSpec.channelNumber = 0; /* munichCtrlCfg.actionSpec.im = 0; /* interrupt mask munichCtrlCfg.actionSpec.res = 0; /* reset munichCtrlCfg.actionSpec.loopi = 0; /* loops for test purposes munichCtrlCfg.actionSpec.loop = 0; /* loops for test purposes munichCtrlCfg.actionSpec.loc = 0; /* loops for test purposes munichCtrlCfg.actionSpec.ia = 1; /* interrupt attention munichCtrlCfg.actionSpec.pcm = 5; /* PCM, CEPT 32 channel munichCtrlCfg.actionSpec.mfl = 256;/* maximum frame length */ */ */ */ */ */ */ */ */ */ */
/*=== Interrupt Queue Specification =====================================*/ /* interrupt queue address */ = &munichIntQueue [0]; /* interrupt queue size */ = (INT_QUEUE_SIZE_MAX / 16 -1); /* Reset interrupt queue */
munichCtrlCfg.intQueueSpec.addr munichCtrlCfg.intQueueSpec.n
for ( i = 0; i < INT_QUEUE_SIZE_MAX; i++ ) { munichIntQueue[i].intFlag = CLEAR; }
User's Manual
249
01.2000
PEB 20320
Appendix
/*=== Timeslot Assignment ===============================================*/ for ( i = 0; i < 32; i++) { munichCtrlCfg.timeSlot[i].rcChannelNumber munichCtrlCfg.timeSlot[i].txChannelNumber munichCtrlCfg.timeSlot[i].rcFillMask munichCtrlCfg.timeSlot[i].txFillMask munichCtrlCfg.timeSlot[i].tti munichCtrlCfg.timeSlot[i].rti }
= = = = = =
/* 0; /* 0; /* 0xFF;/* 0xFF;/* 0; /* 0; /*
For all timeslots assigned to channel 0 all bits assigned per channel Tx output active Rc input active
*/ */ */ */ */ */ */
/*=== Channel Specification =============================================*/ munichCtrlCfg.channelSpec[channel0].intMask munichCtrlCfg.channelSpec[channel0].nitbs munichCtrlCfg.channelSpec[channel0].to munichCtrlCfg.channelSpec[channel0].ta munichCtrlCfg.channelSpec[channel0].ti munichCtrlCfg.channelSpec[channel0].ro munichCtrlCfg.channelSpec[channel0].ra munichCtrlCfg.channelSpec[channel0].ri munichCtrlCfg.channelSpec[channel0].th munichCtrlCfg.channelSpec[channel0].fa munichCtrlCfg.channelSpec[channel0].tflag munichCtrlCfg.channelSpec[channel0].tflagCs munichCtrlCfg.channelSpec[channel0].inv munichCtrlCfg.channelSpec[channel0].crc munichCtrlCfg.channelSpec[channel0].trv munichCtrlCfg.channelSpec[channel0].mode munichCtrlCfg.channelSpec[channel0].iftf munichCtrlCfg.channelSpec[channel0].itbs munichCtrlCfg.channelSpec[channel0].ftda = = = = = = = = = = = = = = = = = = 0; /* interrupts enabled 1; /* new ITBS value 0; /* transmit 1; /* initialization 1; /* 0; /* receive 1; /* initialization 1; /* 0; 0; 0; 0; 0; 0; 0; 3; 0; 9; /* /* /* /* /* /* /* /* /* /* no transmit hold no flag adjustment only for TMA CRC select no bit inversion 16-bit CRC transmission rate HDLC Mode idle code flags transmit buffer size */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */
= txDescr; /* first transmit */ /* descriptor address */
User's Manual
250
01.2000
PEB 20320
Appendix
/*=== Transmit Descriptor ===============================================*/ /* the next pointer of the last txDescr points to the zero pointer for ( ; txDescr ->next; txDescr { txDescr ->fnum = 3; txDescr ->hold = 0; txDescr ->hi = 0; txDescr ->fe = 0; txDescr ->v110 = 0; } txDescr ->fe = 1; txDescr ->hold = 1; = txDescr ->next ) /* /* /* /* /* 3 interframe timefill char */ clear hold bit */ clear host initiated interrupt bit */ clear frame end bit */ clear v110 bit */ */ */ */
/* set frame end bit /* set hold bit
/*=== Receive Descriptor ================================================*/ rcDescr = AllocReceiveDescriptor(10); /* Alloc e.g. ten /* receive descriptors /* with 32 data byte each */ */ */
munichCtrlCfg.channelSpec[channel0].frda
= rcDescr; /* first receive */ /* descriptor address */
/*=== Prepare Receive Descriptor 1 to 9 =================================*/ for ( ; rcDescr ->next; rcDescr = rcDescr ->next ) { rcDescr ->hold = 0; /* not the last descriptor */ rcDescr ->hi = 0; /* no host interrupt */ rcDescr ->no = 32; /* 32 data byte available */ rcDescr ->fe = 0; /* clear frame end bit */ rcDescr ->c = 0; /* clear data section complete bit */ } /*=== Prepare The Last Receive Descriptor, Number 10 ====================*/ rcDescr rcDescr rcDescr rcDescr rcDescr ->hold ->hi ->no ->fe ->c = = = = = 1; 1; 32; 0; 0; /* /* /* /* /* last available descriptor no host interrupt 32 data byte available clear frame end bit clear data section complete bit */ */ */ */ */
channelControl[0].lasttxdescr channelControl[0].lastrcdescr MUNICH32_ACTION_REQUEST (); }
= txDescr; /* store last transmit pointer */ = rcDescr; /* store last receive pointer */ /* generate MUNICH32 activation request */
User's Manual
251
01.2000
PEB 20320
Appendix
/*-------------------------------------------------------------------------- Function : TxHdlcFrame -------------------------------------------------------------------------- Description : Transmit an HDLC frame via channel 0 -------------------------------------------------------------------------*/ static { .. .. void TxHdlcFrame ( MUNICH_TX_DESCR_PTR m32TxDescr )
/* ------------------------------------------------------------------------*/ m32TxDescr = txDescr; /* store transmit descriptor pointer */
channelControl[0].lasttxdescr ->next = txDescr; /* Add frame to existing */ /* channel0 frame queue */ /*=== Transmit Descriptor ===============================================*/ for ( ; txDescr ->next; txDescr { txDescr ->fnum = 3; txDescr ->hold = 0; txDescr ->hi = 0; txDescr ->fe = 0; txDescr ->v110 = 0; } txDescr ->fe = 1; txDescr ->hold = 1; = txDescr ->next ) /* /* /* /* /* 3 interframe timefill char */ clear hold bit */ clear host initiated interrupt bit */ clear frame end bit */ clear v110 bit */ */ */ */ */ */ */ */
/* set frame end bit /* set hold bit /* /* /* /* /* the polling MUNICH32 will then detect the cleared hold bit and send the following frame
channelControl[0].lasttxdescr ->hold = 0;
channelControl[0].lasttxdescr }
= txDescr; /* store last transmit pointer */
User's Manual
252
01.2000

▲Up To Search▲

Price & Availability of PEB20320

	To Download PEB20320 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .